核心问题
为什么不要从头到尾一行行找 Bug？
真实场景
一个流程有十几个步骤：提交表单、校验权限、写数据库、发消息、更新缓存、推送通知。结果最后通知没发出去。
新人可能从第一行代码看到最后一行。资深工程师会先问：
问题发生在流程的前半段还是后半段？
常见误区
坏判断是：
我把代码全看一遍，总能找到。
全看一遍不是不行，但效率低，而且容易被无关细节拖住。
工程视角
二分法的核心是快速缩小范围：
- 用日志判断请求有没有到达后端。
- 用断点判断数据在哪一步变坏。
- 用接口对比判断前端还是后端。
- 用
git bisect判断是哪次提交引入问题。
不是线性搜索，而是分段排除。
PM 可以怎么做
PM 可以帮助把问题切段：
- 用户动作是否成功提交？
- 后台是否收到请求？
- 数据库是否写入？
- 后续异步任务是否执行？
- 通知服务是否成功发送？
每回答一个问题，范围就缩小一半。
Atlas Action
遇到复杂流程 Bug，画一条链路：
用户操作 -> 前端请求 -> 后端接口 -> 数据库 -> 消息队列 -> 下游服务 -> 用户反馈然后逐段标注：已确认正常、未确认、已发现异常。
小结
二分法不是数学技巧，而是一种工程排障习惯。
PM 不需要会打断点，但要会帮助团队把问题拆成可验证链路。