本文不想指责谁，而是传授一些个人经验，帮助你更容易得到答案，如果你经常发现问题问了没人理，那可能是你的提问方法的问题。其实，著名黑客 Raymond 老早之前就写过一篇文章《提问的智慧》，被翻译成了很多语言
简单来讲，一个好的提问者，大概具备如下特质：
- 自己要先努力：为了解决问题自行先做过努力，不是无脑伸手党
- 提供详实的信息：比如版本、配置、日志、你做了什么、看到了什么、尽量截图截全，如果你懒得提供，别人也懒得帮你
- 不做推测：只提供事实截图，如果你的推测是对的，那你还问啥呢，而且有些推测会伤害社区，比如推测是个软件 bug，软件作者一看不是 bug，就更没心情帮你了
- 谦卑有礼貌：社区不喜欢帮助自以为是的、颐指气使的人
- 有回馈分享：问题解决之后能够写一篇帖子或博客分享问题始末，帮助后来者闭坑
自己要先努力
你得首先自己尝试解决，比如百度、Google、chatGPT，检查配置，从日志中找线索，如果你做过努力再提问，和你不做任何努力直接提问，别人一眼就能看出来。自助者天助，古人诚不欺我。
另外，很多问题的发生，大都是不懂原理导致的，先花时间学习一下原理，然后按图索骥，一般问题其实都能解决。
提供详实的信息
对于问题的解决，所有可能带来价值的信息，都应该提供，比如：
- 版本：操作系统版本、软件版本、依赖的某个中间件、数据库的版本
- 配置：你做的事情，涉及到哪些配置，包括软件配置文件、页面上的用户配置，都可能会影响结果
- 时间：很多分布式系统依赖机器时间校准，需要确认各个机器的时间，除了服务端、客户端，还要注意你的浏览器所在的PC的时间
- 日志：软件的日志一般在3个地方：stdout/stderr，日志文件，/var/log/messages，根据你的部署情况寻找日志
- 请求响应：如果是页面报错了，需要打开 chrome 开发者工具，查看报错的请求的 http request 和 http response
- 复现步骤：如何一步一步操作就能复现问题，这个非常非常关键，如果别人可以稳定复现问题，大概率都能得到解决，解决不了的问题，大都是无法复现的问题，可能是环境不同、配置不同、网络不同，别人摸不到你的环境就很难排查了。除非，帮你远程查看，但是又有几个人愿意做活菩萨
- 截图：一定要整页截全，比如某个配置页面，你以为是 A 配置项导致的，实际是 B 配置项导致的，截图截全，会更有利于排查，帮你解决问题的人，都希望一次看到全局，而不是跟你来回交互索要更多截图，像个保姆
不做推测
这个很多人容易忽视。问问题不要做推测，只摆事实截图，因为你的推测大概率是错的，如果你的推测是对的，你就按照自己的推测去解决就好了，干嘛来问别人呢对吧。另外就是一些武断的推测可能会伤害社区，比如推测是个软件 bug，软件作者对这些东西更熟悉，如果他一看不是 bug，立马就会心情不爽，毕竟都是凡人这是人之常情，要么直接忽略了你，要么就是语气不善的撇清关系，当以撇清关系作为出发点的时候，他才懒得帮你解决问题呢。
谦卑有礼貌
这是修养问题，不止是在社区提问，线下与人打交道待人接物也要讲礼貌嘛，只不过是在网络上看不到彼此，很多人就克制不住内心了，更焦躁，更无理。
社区尤其不喜欢自以为是、颐指气使的人。自以为是的典型说辞是：“我是十多年的xx经验的人，社区这个软件的xx设计肯定是不合理的，不是我的使用问题”。颐指气使的人的典型说辞是：“xx用了不好使，抓紧改！这样的软件怎么会有人用！你们自己不测试么！”，一堆叹号，外加一顿PUA，最后排查发现是自己犯了个配置上的小错误，消耗掉了在社区的人设，后面再有问题就很难得到解答。
有回馈分享
问题解决之后，最好的做法是写一篇帖子或者博客，来分享问题的来龙去脉以及解决思路，帮助后来人避坑。很多人没有写东西的习惯，可以理解，但不推荐，推荐的做法是：写！好记性不如烂笔头。而且，社区看到这个人有分享回馈，会更愿意帮助他。
差的行为举例：在 Github 提了个 issue，有些人提供了解决思路，最后提问者回复：已解决，关闭 issue。别人不知道是怎么解决的，不知道有哪些坑，不知道哪个网友的建议是对的。
One more thing
俗话说有钱能使鬼推磨，建议发问题之前先发个红包（封皮就写“求助”），红包金额可以很小，但是能炸出很多潜水的。然后别人领了红包你再发问题，吃人嘴短，就更容易得到建议。
平时在社区多多帮助别人，你有的问题的时候，才会有更多人愿意帮你，这个道理不用多讲。付出就像存钱，提问就像取款，社区允许一定程度的借债，但不欢迎无底线的老赖。
小结
以上是我个人的几点强烈建议，更详细的提问的智慧请阅读 Raymond 的著作：《提问的智慧》。
