调试只能靠猜？用二分法把问题范围砍半

改代码最耗时间的不是写，而是找问题。很多人遇到异常后的第一反应是“可能这里有问题”，改一改试试，不行再改另一处。这种方式在复杂系统里效率极低，因为你实际上是在随机搜索，而问题的可能范围可能有上千行、十几个模块。

为什么“靠猜”效率低

调试的本质是搜索。搜索效率取决于每一步能排除多少可能性。直觉式的修改每次只能验证一个假设，而且假设的来源往往是“最近改动的地方”或“以前出过问题的地方”——这两个线索的命中率随系统复杂度下降。与之相对，二分法的每次操作都能把可能范围缩小一半：一千行的范围，十次判断可以定位到单行。如果是靠猜，期望次数要高得多，而且人为制造改动还可能引入新问题，把搜索范围越弄越大。

二分法的三种落地形态

• 代码级二分：在流程中点插入日志或断言，把执行路径切成两段，判断问题发生在前半还是后半。例如一个函数有多个分支，在中间位置打印输入输出，立刻能判断问题在进入前还是处理中。
• 数据级二分：当问题与数据相关（某批订单计算错误、某个用户查不到数据），先用一半数据跑一遍，再缩小到出错的那一半。这比逐条排查快得多。
• 版本级二分：问题在某个时间点出现但不知道哪次提交引入的，用版本控制工具在提交历史中取中点测试，逐次收窄。这是最省力的定位方式，前提是提交粒度足够小——所以小步提交不仅是习惯问题，也是调试能力的基础。

二分之前：先让问题可复现

二分法有个前提：你需要一个稳定的判据。如果问题时有时无，先别急着缩小范围，而要先把复现条件固定下来：固定的输入、固定的环境、固定的数据版本。这一步常被跳过，结果是在不确定的判据上做二分，得出错误的结论。一个实用的技巧是把复现步骤写下来——写的过程本身会暴露你不确定的环节。

一个对照案例

一个接口偶发超时。甲凭直觉先怀疑数据库索引，花两天加索引、改查询，问题依旧，随后又怀疑网络、怀疑缓存，一周过去仍无结论。乙的做法是先抓取足够多的失败请求样本，固定复现路径，然后在调用链的中间层加一段耗时打点，半小时内确认耗时集中在序列化环节，接着在序列化内部二分，最终定位到一个在循环里反复创建对象的写法。两人最终找到的是同一处问题，差别在于甲花了一周，乙花了半天——因为乙每一步都在排除一半。

常见误区

• 没有稳定复现就开始改代码。判据不稳定，任何结论都不可信。
• 一次改多处。多变量同时变化后，你无法判断是哪一处起了作用。
• 忽略“问题真的存在吗”。有些报错来自环境差异或过期缓存，先确认预期本身是否正确。
• 只修不记。没有记录根因与判据，同类问题下次还要重新排查一遍。
• 把调试当运气。调试是可以被工程化的：判据、打点、二分、记录，四步固定下来。

行动建议

下次遇到问题，先做两件事：用一句话写下“什么条件下必然出错”，然后在流程中点加一次打点，判断问题在前半还是后半。只做这两步，你的定位时间通常就会下降一半以上。把这个习惯重复几次，它会取代“先改一处试试”的本能反应。

把定位过程固化成可复用的判据

一次成功的调试如果只解决了一个问题，价值只用了一半。花五分钟把三件事记下来：问题的稳定复现条件、最终定位到的位置、以及当初误导你的那几条线索。积累几次之后，你会发现自己常犯的判断偏差会形成模式——例如总先怀疑数据库、总忽略缓存、总在最后才检查配置。这些模式比任何一个具体问题的解法都更有价值，因为它们能缩短下一次的搜索路径。