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

无他，唯手熟尔

有些 bug 就是没什么道理的，我甚至用过二分法查找 bug...

熟悉底层知识 杜绝玄学编程

连续一段时间解决不了，就先放一放回头再分析

只要问题能重现，bug 都好处理。所以有时为了重现问题用各种暴力方法，比如用脚本频繁触发某一个操作。或模拟多个用户同时做相同的操作。之前还遇到过用户鼠标有问题，经常单击变双击导致接口调用 2 次的问题(当然也是代码没有控制好，但普通测试不容易发现)

排除法，首先不是自行车

bug 哪有抽象的，bug 都是眼睛看出来的

你这个场景上一套 APM 就可解啊，从接口开始一直可以跟踪到 SQL 查询，排个序就能看出哪些接口在哪些参数条件下执行哪个数据库查询时间特别长

搞 APM 挺好，但是很多公司不注重这个

良好设计+熟悉架构+清晰的底层逻辑理解
外加无它唯手熟尔

多锻炼自己不依赖调试器定位问题的能力，当你能把 bug 锁定在某个模块内部的时候，一般目视检查就可以发现问题。

@snipking 正常系统慢 sql 一查就知道了，为什么慢你 explain 一下还不一定看出来，如果现场一旦丢失了的话，复现纯靠猜测，我们领导都是做技术的，第一时间来问你回答不出来真的焦头烂额

让我查了 N 多小时的 bug ，原因却不复杂

http://xhslink.com/BQgTwN

全靠同事、领导

多斗争几次，拒绝多线程编程，解决大部分玄幻问题

bug 指代码里的问题。bug 抽不抽象取决于你的代码写得抽不抽象。所以如果遇到的代码很抽象说明自己的代码写得很抽象。代码写得抽象说明菜。
菜就多练

处理用户反馈的各种非必现的奇葩问题才难受

程序使用了多数据源，开头还好，现在不知道为什么一启动就报错，druid 初始化时弹出来个不支持 hsqldb 的错误，我猜测是哪个包使用了 hsqldb 来作为内存缓存，但是根本解决不了，烦死

靠运气加上执着

@imboring ＃ 2

这是很常规 debug 方法

@hejiangyuan 罗技：那必须是我了😀

复现问题、抓异常日志、debug 日志看详细调用链、代码分析、Arthas 反编译比对代码、Arthas 拦截、调用链查看，一般这样只要能复现的问题都能排查出来，比较难的是偶现甚至不可复现，理论上不可复现你也没法验证修复，所以可复现是必须的。还有一种是开源框架内异常，这种一般是少了什么配置或依赖导致的，报错与实际差异可能完全不一样，需要熟悉开源框架的运行原理，然后分析源码和看文档排查。

删

@guguji5 你这感觉是经验不足一般我写放在 usereffect 依赖里面的应该保证都是状态不要直接用变量 eslint 有个选项也可以帮你完成这个

可复现的就在上下加一整套观测方法， 就像 21 楼说的那样
不可复现的，那能叫 BUG 么？不理，找到稳定复现方式了再处理

大部分是在梦里解决的，我说的解决是真的有解决办法的那种解决。

直觉。。。

经验+猜测+验证+猜测+验证...，循环往复，有些 bug 的发现真是纯靠执着。 数据异常、数据波动类的问题，可以用我的开源项目解决： https://github.com/xl-xueling/xl-lighthouse

世界上没有抽象的 bug

只有 print 不够多的代码（

白眼看空格，之前遇到若干奇葩问题是因为多了个空格，比如密码粘错，ng 配置失效，然后让对方用鼠标框选一下，果然......

share 一个概念：确定性模拟。很多 bug 难以复现主要是由于系统中不确定性的因素太多了，例如网络延迟，进程调度等等都会导致不同的执行历史，而某些 bug 只有在特定的执行历史下才会复现。

特别对于我们做分布式系统的人来说，平均半年才复现一次的 bug 也不少见，写过共识算法的人应该都能理解。而如果故障现场的日志和信息不足，基本没有排查的可能。

确定性模拟的方案就是通过模拟器，将一切不确定的事物转变为确定性的，整个系统在模拟器上运行 结合故障注入，当 bug 出现时，只要记录模拟器最初的 seed ，使用同样的 seed 再次运行 就能复现当时的执行历史。同时，时间也是输入的一部分，系统相当于一个随着时间不断变化状态的状态机，因此在模拟器上并不需要真正等待时间流逝，模拟器可以直接跳转到系统这个状态机的下一个状态，实现时间加速的效果。

具体实践可以看看这个项目： https://github.com/madsim-rs/madsim?tab=readme-ov-file
及其在 RisingWave 的落地： https://risingwave.com/blog/deterministic-simulation-a-new-era-of-distributed-system-testing/，https://risingwave.com/blog/applying-deterministic-simulation-the-risingwave-story-part-2-of-2/

按图索骥呗

没办法只能靠经验猜 有些 bug 解决了也不知道 bug 产生的原理是什么 有些 bug 真的是不讲逻辑的

一定数量的经验 + 直觉

@iosyyy 那个 eslint 具体怎么设置，可以说一下嘛？

@iosyyy 你说的对。虽然已经写了 3 年 react 了，但是依然是这吊水平。

@crazyu exhaustive-deps 我们现在用的是这个不过我试了下好像不支持这个 感觉我有点印象流了..

@crazyu 大概率是记错了

@billbur apm+日志的信息，绝大多数情况下你都能复现出来，你觉得复现不了那说明监控还没做到位

我现在就有一个离谱的问题，支付宝小程序请求偶尔会提示超时，但是无法复现，官方的质量检测有记录到，千分之几的概率。为此查了 nginx 日志，程序日志都没看到问题。

偶尔真机调试的时候会看到请求接口缓慢，耗时都在 Dns lookup 上，大概 5~10s ，猜测是 dns 问题，换了 dns 服务商，没用。后面看到证书认证失败也会报这个错，换了新 ssl 证书，还是没用，到现在也没解决呢。。

添加多个日志输出点，逐步缩小 BUG 的代码范围。多线程的情况下就减少线程数

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

@Hyschtaxjh 严肃点，那叫 feature

这题无标准答案，case by case

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

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

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

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

玄学的最后都是科学。

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

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