我靠这 4 个调试习惯，少加了无数次班

做开发这些年，我越来越觉得：写代码是和编译器对话，调试才是和真实世界对话。你以为逻辑天衣无缝，一跑起来全是意外。而调试能力的差距，直接决定了你是准时下班还是通宵抓虫。

我刚入行时调试基本靠玄学——System.out.println("here1")、System.out.println("here2")，满屏的 here 和变量值，像在犯罪现场撒面包屑。后来被一个 Bug 折磨了整整两天，最后发现是缓存里一个字段被别的线程偷偷改了。那次之后，我彻底重构了自己的调试方法论。

习惯一：先复现，再动手

这可能是最反直觉的一条。很多人一看到报错就迫不及待改代码，觉得"大概是这个原因"。我以前也这样，结果改了半天发现方向完全错了。

现在我的规矩是：不能稳定复现的 Bug，不急着修。先花时间找到复现路径——输入是什么、环境是什么、时序是什么。能稳定复现的 Bug，本质上已经解决了一半，因为你随时可以验证自己的修复是否真的有效。

有一次用户反馈"偶尔登录失败"，我们试了一周都复现不了。后来我在登录接口里加了详细的 trace 日志，专门记录 session 的创建和销毁时序，才发现是负载均衡下两个节点间的 session 同步有 50ms 延迟，用户在极短时间内的二次请求落到了另一个节点上。找不到复现路径，这个问题可能永远是个谜。

习惯二：二分法定位，别线性排查

代码量大了以后，一个请求可能经过几十个类、上百个方法。从头到尾看代码效率极低。

我的做法是二分法：在调用链的中间位置打一个断点或加日志，确认问题出在前半段还是后半段，然后继续二分。就像二分查找一样，几次就能锁定到具体方法。

之前排查一个"订单金额计算错误"的问题，整个链路涉及价格服务、优惠服务、税费服务、汇率服务。我在中间加了一行日志，发现调用优惠服务之前金额还是对的，之后就错了——直接锁定优惠服务，省了至少两小时的盲目排查。

习惯三：学会读堆栈，而不是只看第一行

新手看异常堆栈，往往只看第一行报错信息，然后去搜错误信息。但堆栈的真正价值在完整调用链——它告诉你代码是怎么一步步走到出错位置的。

我养成了一个习惯：遇到异常，从下往上读堆栈。最下面是入口（比如 Controller 方法），最上面是真正抛异常的地方。沿着这条链，你能看到数据在哪个环节被改变了、哪个外部调用返回了意外结果。

有一次生产上报 NullPointerException，报错在工具类的第 47 行。如果只看那一行，完全看不出为什么为空。我从下往上读了完整堆栈，发现是上游一个 RPC 接口在某个边界条件下返回了 null 而不是空对象，而我这边没做判空。堆栈帮我还原了整个"作案过程"。

习惯四：远程调试 + 条件断点，效率翻倍

很多人觉得调试只能在本地 IDE 里做，生产环境只能靠日志。其实不是。

我们线上环境开启了 JPDA 远程调试端口（当然只在非高峰期、且经过审批），我可以用 IDEA 远程 attach 上去，设断点、看变量、单步执行。尤其是 条件断点——比如"当 orderId == 12345 时才停下来"，这在排查特定用户/订单的问题时简直是神器，不用在海量请求里手动筛选。

当然，生产环境远程调试要谨慎，不能影响正常请求。我们的做法是：只在问题无法在测试环境复现时才用，而且只在流量低的时候操作，断点设为"只挂起当前线程"而不是全部。

一个额外心得：日志是最好的调试工具

调试器再强，也有用不了的时候——比如多线程竞争、异步回调、生产环境受限。这时候，好的日志就是你的眼睛。

我现在写代码有个习惯：在关键分支、状态变更、外部调用前后都留日志，而且带上足够的上下文。不是说越多越好，而是在"如果这里出问题，我需要什么信息来定位"的地方留日志。这就像给未来的自己留线索。

调试这件事，说到底是一种思维方式——你不是在找 Bug，你是在还原真相。每一条日志、每一次断点、每一行堆栈，都是线索。耐心一点，方法对一点，大部分 Bug 其实没那么难抓。

如果你现在还在靠 print 大法调试，不妨试试上面这几条。不用一步到位，但每掌握一个，就少熬一个通宵。毕竟，头发和时间，都是不可再生资源。