程序调试别靠瞎猜：二分定位与最小复现
每个程序员都经历过这样的夜晚：线上出了个Bug，你盯着代码看了两个小时，觉得每一行都合理，可它就是不对。新手和老手的差距，往往不在写代码，而在调试——新手靠直觉瞎试，改一行跑一下，越改越乱；老手有一套方法，像侦探破案一样，稳定地把问题范围一步步缩小。调试不是玄学，而是一门可以练习的科学：先复现，再定位，最后修复。
为什么”瞎猜”注定低效
一个Bug的产生，往往是多个条件叠加的结果：某段代码本身没错，但和特定的输入、时序、环境凑在一起就错了。人脑一次能同时追踪的变量有限，面对动辄几千行的调用链，靠”读代码猜原因”就像在大海里捞针。而且人有一个致命弱点：确认偏误——一旦你心里有了”可能是缓存问题”的猜测，就会不自觉地只找支持这个猜测的证据，忽略其他线索。方法化的调试，本质上是设计一套流程，逼自己绕开直觉的陷阱。
调试四步法：把玄学变成流程
- 最小复现：先问三个问题——什么输入、什么环境、什么操作顺序会触发Bug？把触发条件压缩到最小集合（比如”当订单金额为0且使用优惠券时崩溃”），写一个能稳定复现的测试。不能复现的Bug无法验证修复，等于没开始。
- 二分定位：不要从第一行往下读，也不要乱加日志。沿着数据流从入口到出口，在中间点打日志或断点，看状态对不对——对了就查后半段，错了就查前半段，每次把搜索范围砍半。一个千行模块，十次二分之内必然锁定到几十行。
- 提出假设再验证：定位到嫌疑代码后，先问”什么条件下这里会出错”，写出你的假设，再用最小复现去验证。一次只验证一个假设，改一处代码，跑一次测试——同时改三处再测试，出了新问题你都不知道是哪处引起的。
- 修复后回归：修复完成不是”能跑了”就结束，要把最小复现固化成自动化测试，防止它改天复活；再想一步：同类问题在别的地方还有没有？
日志是调试的利器，但要讲策略：在”数据流的关键节点”打日志，记录输入、输出和中间状态，而不是满屏print。生产环境排障时，分级日志（error/warn/info）和链路追踪ID能让你在分布式系统里顺着一次请求从头查到尾。
案例：一个查了三天的问题，十分钟定位
某团队线上订单偶发”支付成功但状态没更新”，三天没查出来。新人小陈接手后没有去翻代码，而是先从日志里捞出最近20个出问题的订单，对比正常的订单，发现一个规律：出问题的订单全部来自某个渠道，且都发生在晚上10点后。再查发现，该渠道的回调是异步的，而晚上10点恰好是系统定时任务批量清理订单缓存的时间——回调更新状态时读到了被清空的缓存，静默失败。整个定位过程不到一小时：先找规律缩小范围，再查边界条件。前面三天查不出来，是因为大家都在”读代码猜”，而真正的线索在数据里。小陈后来总结：遇到诡异Bug，先别碰代码，先去日志和数据里找规律——Bug会留下痕迹，只看你愿不愿意当侦探。
常见误区
- 一上来就改代码：没复现、没定位就动手改，十有八九是拆东墙补西墙，还容易引入新Bug。
- 同时验证多个假设：一次改三处，测试通过了也不知道是哪处起的作用，等于没学会归因。
- 忽视”最近改了什么”：线上Bug大半是最近一次发布引入的，先用git diff对比最近改动，常常一击即中。
- 修完不写回归测试：同样的Bug在另一条路径上复发，是团队最常见的”二次事故”，根因就是修复没有固化。
行动建议
下次遇到Bug，给自己定三条纪律：第一，复现不了不碰代码；第二，定位过程中每个假设只改一处、只测一次；第三，修复后把复现用例变成自动化测试。再养成两个习惯：git提交前先diff一遍”这次改了什么”，排查时先看最近改动；日志里给关键节点打上结构化信息。当调试从”灵光一现”变成”按流程破案”，你省下的不只是时间，还有半夜被叫起来看线上事故的头发。