看不懂的代码怎么排障：先把行为契约摸出来，再谈改

接手一段完全看不懂的代码，出了 bug 要修。这时候最糟的做法是从头读，读到第三天还没定位。分享一套实用的排障顺序。

第一步：定义正确行为，不读代码

先写清楚「输入什么、应该输出什么、边界在哪」。用一段脚本把当前行为跑出来，记录实际输出。差异点就是问题所在的范围，先缩小范围再读代码。

第二步：二分定位

用 git bisect 找引入问题的提交，比读代码快得多。如果没有版本历史，用注释法二分：把可疑模块短路掉，看问题是否还在。五次之内能把范围压到一个函数。

第三步：看输入输出，不看实现

在模块边界打日志，记录进出的数据结构。很多所谓的「莫名 bug」是数据形状不对：字段名大小写、null 与空字符串、时区、浮点数精度。

第四步：复现最小案例

把触发条件剥离到最小的一百行脚本。这个过程本身经常就把答案暴露出来，因为剥离时会发现某个隐含依赖。

第五步：才读代码

到这一步范围已经很小，读起来有目标。重点看三处：状态修改、异常吞掉的地方、并发共享的数据。

遗留代码的特殊之处

最坑的不是逻辑复杂，是没人知道某段代码为什么这么写。改之前先搜提交记录与工单号，找不到就当作有原因，别删。

加日志、加断言、加测试，是安全的介入方式。直接重构是不安全的。

一句经验

排障的本质是缩小搜索空间，不是理解全部代码。想全懂再动手，往往来不及。

看不懂的代码怎么排障：先把行为契约摸出来，再谈改示意图

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。