确保自己阅读过至少一次官方文档。这样在遇到问题时，如果能回忆起只言片语，就可以再去读一遍相关文档，问题往往也就解决了。
开源软件一般都会有自己的 Bug 管理方案，比如 WebKit、V8、jQuery、SeaJS 等等。从它们的官网上找到 Bug 管理地址，然后通过搜索看看有无你遇到的问题。对于活跃社区来说，这一招经常很管用。比如 jQuery 的Bug Tracker，通过右上角的 SearchTickets 可以找到非常多有用的信息。一个运作良好的 Bug 库，经常是一座巨大的宝藏。
提问有很多种，比如你认识作者，直接面对面请教就行。下面探讨的是如何通过互联网的方式来问问题。
如果遇到问题的软件有专门的 Bug 管理系统，请最好到这些指定系统中提交。比如 BladeX 和 SpringBlade 就有专门的技术社区
QQ、阿里旺旺、等群组。这些群组主要是用来用户之间交流和获取官方更新信息的。在这些地方提问，作者一般不会关注，效率非常低。而且问题也无法积累到知识库，属于同一个问题要回答无数遍，不推荐。
微博、Facebook 等社交网络。不少人在微博上通过 at 或私信询问问题，这些我经常看不到。看到了，也不情愿回复。微博是扯淡、交流情感的地方，一般是写代码写累了，才去逛逛，很少会有在社交网络上回答技术问题的心情。
通过正确的途径提交问题，一般可以让你的问题得到及时准确的回复。
如果社区提供了问题模板，一定要仔细看下。比如 Google Code 社区，当你创建一个问题时，会自动提供以下模板：
What steps will reproduce the problem? 该问题的重现步骤是什么？ 1. 2. 3. What is the expected output? What do you see instead? 你期待的结果是什么？实际看到的又是什么？ What version of the product are you using? On what operating system? 你正在使用产品的哪个版本？在什么操作系统上？ Please provide any additional information below. 如果有的话，请在下面提供更多信息。
遵循这个模板去描述问题，经常能省很多事。作者一般也非常欢迎通过模板提交的问题。如果社区没有提供模板，也可以自己遵循以上模板来提交。
下面针对问题内容，具体说说一些需要注意的点。
事实是指，依次进行了哪些操作、产生了怎样的结果。比如
我在 开发机 macos 系统 下用 chrome 打开 saber 后，在用户管理模块新增了一个功能，这时浏览器弹出脚本错误提示，期待功能显示不正确。
我的具体代码如下，重现步骤如下，请帮忙查找问题主要出在哪里
xxxxxx
xxxxxx
上面是一段比较好的事实描述（更好的是把错误提示也截图上来），而不要像下面这样猜测：
saber开发了一个功能，打开报错，怎么解决。
上面的描述，会让作者一头雾水、甚至很恼火。尽量避免猜测性描述，除非你能先描述事实，在事实描述清楚之后，再给出合理的猜测是欢迎的。
如果能提供可重现错误的在线可访问代码，那是最好不过的。一旦你这么用心去做了，作者往往也会很用心地立马帮你解决。
如果提供不了，也可以把代码完整打包发到官方的邮件，bladejava@qq.com
无论在开源社区，还是微博、知乎等平台上，有一种非常常见的问题：
如何维护 JavaScript 代码？
如何使用 SpringBlade 进行模块化开发？
这类问题还有很多，每每遇到，只能笑笑，然后悄悄地忽略掉。因此这类问题很难回答，就如下面这些问题一样：
如何才能让生命有意义？
如何打败淘宝？
这类提问者，一般比较浮躁，经常对问题本身也没有经过思考。踏实的提问者，不会让问题浮在空中无法回答，而会在具体场景中让问题落地：
我的项目有 20 多个 JS 文件，接下来还会急剧增加。目前遇到以下问题……（省略五百字）…… 请问如何维护？
提交问题后，建议通过邮件等方式订阅回复。互联网上最有效的沟通方式是异步沟通，不要期待作者马上回复，也不要心烦意乱着急地等待。出去看看天，数数云朵，你会逐步明白什么是风轻云淡。
当问题终于解决时，建议对问题进行总结。可以编辑原帖，也可以通过博客等方式总结。你的总结，会让遇到同样问题的朋友们受益，并且对自己的技能也是一种提高。前端业界，无论国内还是国外，有很多牛人之所以成为牛人，很大程度上都是因为有总结思考的好习惯。
扫一扫访问 Blade技术社区 移动端
苏公网安备 32041102000998号