大家平时都是怎么找一些很抽象的 bug 的

[billbur]

我一般靠日志和 debug 都能解决大部分 bug ，这些都没什么好说的，但是遇到一些非常规手段就能找到问题原因的 bug 就纯靠经验然后做假设再验证了。比方说之前遇到过一次数据库表的统计信息不准确导致 sql 不去走索引，后面又走索引了搞的我们查问题查的要死。 想听听大家的经验之谈，在可以分享的范围内细说，学习学习

[Hyschtaxjh]

看了一圈都在讲技术 bug ，没有讲业务 bug 的，那叫一个抽象难受。

[snipking]

@Hyschtaxjh 严肃点，那叫 feature

[liyafe1997]

这题无标准答案，case by case

我讲一个以前的真实经历，可供参考。

有个项目内部迭代好多个版本了，测试一直没问题，直到有一次改了一个和 A 模块完完全全不相关的 B 模块，A 模块就寄了，但是只要按 Ctrl+Z 把那几行更改撤销，A 模块又恢复正常了。

当时真的是研究这个玄学折腾了好久，几号人一直在 B 模块那找线索，也 debug A 模块，然后很大的心思在试图找到 A 和 B 之间，以及那个更改是否有一丝丝关联，但是就是毫不相关，完全不搭噶。

然后尝试重新审视出问题的 A 模块，尝试重新实现，重新读各种文档，果然发现了问题：A 模块的一个数据的内存地址有对齐要求，之前跑路的人自己没仔细看文档，留了个雷，没有强制对齐，然后之前编译的版本都碰巧对齐上了，所以迭代了好多次都没出问题，直到这次改了个毫不相干的地方，可能导致内存布局整体挪了一下，然后正好没有对齐上，一下子就爆雷了。

玄学的最后都是科学。

[luzemin]

出现解决不了的 bug ，我一般都是出去走走，缓解一下焦躁的情绪，然后回来让 leader 把 bug 指给其他人，我搞不定。

[cpluspython]

测试的期间就有意的留意操作的步骤和触发的服务. 让测试的过程是变量可控的, 这样复线也更有迹可循. 如果是很偶然的情况下出现的, 那就尽力还原当时的测试环境, 往这个方面着手. 除了当时的测试环境, 还有相应的接口数据流转, 页面代码执行逻辑等. 总之就是尽力还原, 然后去试.