夜雨聆风
当面试官问：有一个偶发bug，要如何复现并处
考察候选人是否具备系统化的 bug 排查思路，能否通过日志、埋点、监控、环境还原和工具手段复现偶发现象并定位根因。
一、面试口述版回答稿（直接背）
如果遇到一个偶发性的 bug，其实我的第一反应不是立刻去改代码，而是先冷静下来，把问题拆开一步步分析。因为偶发问题往往说明它跟环境、数据状态或者并发条件相关。
我的第一步一般是收集信息。我会先问清楚这个 bug 出现的上下文，比如它发生在什么时间点、什么操作步骤下、在哪些机型或者网络条件下。很多时候，用户口头描述不够准确，我会去要现场的截图、接口返回数据，甚至日志片段。
第二步，我会尝试复现。复现是关键，不复现基本没法解决。我会在相同环境下重复操作多次，看能不能把 bug 逼出来。比如如果它只在弱网环境下发生，那我会模拟弱网；如果怀疑跟并发相关，那我会写脚本或者用 JMeter 去压测，让 bug 出现得更频繁一些。
第三步，我会利用日志和埋点定位。偶发问题通常单靠肉眼复现是不够的，所以我会重点看 TraceId 链路，把一个请求从网关到应用到数据库的日志串起来。很多时候 bug 出现的瞬间，日志里已经有了异常提示。必要的时候，我会加一些临时埋点，把输入参数和关键步骤都记录下来，下次再出现时就能知道是在哪个环节掉链子。
比如我之前就遇到过一个偶发的支付 bug，用户说钱扣了但是订单没生成。当时问题很难复现，我就用压测工具模拟高并发支付，最后发现订单更新的 SQL 没有加索引，高并发下被锁阻塞，导致上游服务超时。后来我们给 SQL 加了索引，并在调用端加了幂等校验，问题才彻底解决……
二、项目实战讲解（STARR 法则）
– 背景：在一次支付测试中，偶尔会出现订单扣款成功但状态未更新的情况，用户反馈“钱扣了但没生成订单”。
– 目标：复现并定位 bug 的根因，确保支付链路数据一致性。
– 执行：
– 收集用户反馈日志，发现问题只在高并发场景下偶发……
三、困难点 & 解决方案
1. bug 偶发，无法稳定复现
– 解决方案：用压测工具或脚本持续模拟，增加触发概率。
2. 日志不全，缺乏关键信息……
字数格式限制🚫，查看全文⬇️
