话再多而不在精

你需要提供精确有内容的信息。这并不是要求你简单的把成堆的出错代码或者资料完全转录到你的提问中。如果你有庞大而复杂的测试样例能重现程序挂掉的情境，尽量将它剪裁得越小越好。

信息要足够，但不要堆砌

“详细”不等于“把所有东西都贴上来”。日志、配置、代码、截图和错误信息都应该经过筛选。你需要保留能支持诊断的事实，删掉和问题无关的噪声。

如果问题可以用 20 行代码复现，就不要贴整个项目。如果错误只出现在最后 30 行日志里，就不要把几万行日志直接塞进正文。

最小化问题的三个价值

这样做的用处至少有三点。 第一，表现出你为简化问题付出了努力，这可以使你得到回答的机会增加； 第二，简化问题使你更有可能得到有用的答案； 第三，在精炼你的 bug 报告的过程中，你很可能就自己找到了解决方法或权宜之计。

一个实用标准

在发问前问自己：回答者是否能用你给出的材料复现或理解问题，同时又不必在大量无关内容里搜寻线索？如果不能，就继续裁剪、整理和标注重点。