没有AI的日子里，程序员靠什么Debug？

一、引言：调试是程序员的“童子功”

AI Coding 兴起不过是近几年的事。在更漫长的岁月里，程序员这个行当的工匠艺人们，靠一套代代相传的 Debug 奇技淫巧吃饭：读日志、打断点、补打印。这些方法听起来朴素，背后却是一整套严谨的问题定位方法论。即便今天有了AI助手，理解这套方法论的来龙去脉依然能让你在排错时事半功倍——因为AI定位问题时所依赖的输入，恰恰就是这些基本功的产物。

下文按照“错误日志 → 断点调试 → 打印日志 → 进阶心法”的顺序，把这套老手艺完整拆解一遍。

二、第一招：精读错误日志，从“第一现场”提取线索

遇到报错，第一步永远是看日志，这是所有调试动作的起点。一份错误日志通常包含三类关键信息：错误类型（空指针、越界、超时等）、错误消息（人类可读的描述）、调用堆栈（问题发生的完整路径）。

1. 堆栈要“自上而下找自己人”。 很多初学者被几十行堆栈吓退，其实有效的读法是：跳过最顶部的系统帧，定位第一个属于自己代码的帧——那一行往往就是“案发现场”。顺着堆栈再往下读，还能看清完整的调用链路，帮你还原程序是怎么一步步走到这里的。

2. 不认识的报错，先搜再问。 把关键报错信息拿到搜索引擎和技术社区搜一遍，是那个年代程序员的肌肉记忆。搜索有个小技巧：报错原文里混着本地路径、变量值、时间戳这些“环境噪音”，复制时要裁剪掉，只保留与错误本质相关的部分，否则会搜出一堆无关结果。技术问答社区和开源项目的问题追踪列表里，大量常见报错都有前人踩过坑、留过答案。

3. 和AI的做法对照一下。 AI定位问题同样需要错误日志。它的优势在于“见过”的报错案例足够多，能根据日志更快地把嫌疑范围收敛到某一行。但万变不离其宗——高质量的错误日志，无论对人还是对AI，都是定位问题的第一等输入。

三、第二招：断点调试，让程序在你眼皮底下“慢下来”

看懂日志、锁定嫌疑行之后，下一步通常就是断点调试：让程序在指定位置暂停下来，逐行观察运行时的变量值与预期是否一致。

1. 适用场景。 断点调试特别适合“能大概猜到出错位置”的情况：在重点怀疑的代码行打上断点，程序停下来后检查变量；没问题就直接放过，继续跑到下一个断点，直到逮到那个“值不对”的瞬间。它把“猜”变成了“看”，是验证猜想最直接的手段。

2. 常用操作的心智模型。 现代IDE和浏览器开发者工具普遍支持这套操作：单步跳过（执行当前行、停在下一行）、单步入步（进入函数内部）、跳出（执行完当前函数）、继续运行（跑到下一个断点）。此外还有两个容易被忽视的利器：条件断点（满足某个表达式才暂停，适合循环中偶发出错）和日志断点（不暂停、只打印，适合不宜中断的场景）。

3. 前端场景的特殊性。 前端代码经过构建压缩后，浏览器里看到的往往是一串“天书”。此时要依赖构建产物中的 sourcemap，把压缩代码映射回源码：在控制台里点击报错行号，就能跳转到对应的源码位置打断点，让程序在该位置停下来，调试体验立刻恢复。

4. 局限要有数。 断点调试依赖“可交互、可暂停”的环境。对时序敏感的并发问题、跨服务的分布式问题，暂停本身可能改变程序行为，此时就要换打法——交给打印日志。

四、第三招：打印日志，专治“程序吞掉了错误”

最麻烦的一类问题是：程序表现异常，但日志里一片祥和。常见原因是内部某处 try-catch 住了异常，捕获之后既不打印也不上抛，错误就像被程序“吞掉”了一样：

try {
    doSomethingCritical(input);
} catch (Exception e) {
    // 空的 catch 块：异常被静默吞掉
}

这种坑尤其常见于第三方组件或jar包内部——组件在你不知情的情况下降级、容错、吞异常，外部只看到结果不对，完全看不到过程。坦白说，这类问题就算交给AI也很难搞定，因为AI同样缺少“过程证据”。唯一靠谱的办法是补全日志：

1. 沿调用链补日志。 重点怀疑组件调用的前后位置，把入参、出参、关键中间变量统统打出来，先检查自己的入参是否符合组件的契约要求——很多“组件的bug”，其实是自己传参不合规。

2. 先理顺执行顺序，再动手补。 补日志之前，要先在脑中把程序的真实执行路径走一遍：谁先调谁、异步任务何时返回、哪个环节可能提前返回。顺序理不顺，日志就打不到点子上，只能从头逐行大海捞针，非常痛苦。

3. 吞异常必须留痕。 规范的做法是：捕获之后至少记录日志，再决定是修复、降级还是上抛：

try {
    doSomethingCritical(input);
} catch (Exception e) {
    log.error("doSomethingCritical failed, input={}", input, e);
    throw new IllegalStateException(e); // 修复或上抛，但绝不能无声无息
}

顺带一提，如今主流云平台（例如百度智能云）提供的日志服务类产品，已经能统一收集、集中检索散落在各台机器上的日志，比当年“登服务器翻文件”的排查效率高出一大截。

4. 一段痛苦但典型的经历。 十年前我从事嵌入式开发时，打印日志是最高频的调试手段，代价也最大：程序必须拷贝到U盘、插到板子上运行，每加几行日志就要重新拷贝、重新上板跑一轮，一次排错动辄几十次插拔。正是这种“改一次成本极高”的环境，逼人养成了“先想清楚、一次补够”的习惯。反过来想，今天改一行日志就能立刻重跑的环境，已经是巨大的幸福了。

五、进阶心法：三板斧之外还有招

1. 二分法定位。 嫌疑范围太大时，别逐行排查，用二分：代码层面，临时注释掉一半逻辑看问题是否复现，几轮就能收敛到具体片段；版本层面，利用版本控制工具普遍提供的“二分定位”能力，在历史提交中快速锁定引入问题的那一次改动；环境层面，把正常环境与异常环境的配置、数据逐项对切，找出差异变量。

2. 构造最小可复现用例。 把问题从庞大业务代码中剥离出来，用最少的代码、最简单的数据稳定复现。这一步价值巨大：一旦复现被简化，答案往往自己浮出水面；即便没有，一个干净的最小用例也能大幅提高你向同事、社区或AI提问的命中率。

3. 讲给别人听。 所谓“橡皮鸭调试法”的精髓在于：把问题的来龙去脉完整讲一遍，讲解过程会强迫你把跳过的细节补齐。很多次话说到一半，自己就意识到了问题在哪。

4. 先问“最近改了什么”。 新问题往往源自最近的变更：新上线的配置、新合入的代码、悄悄变化的数据格式。先对照提交历史和变更记录，往往比从零开始排查快一个数量级。

六、AI时代，基本功依然是”1”，AI是后面的”0”

回头看，这些老方法与AI并不对立，而是递进关系：AI定位问题需要你提供错误日志，日志的完整度决定它的判断质量；你向AI描述问题时，需要像当年向社区提问一样，给出最小复现、环境信息和已排除项；而AI给出的修复建议，最终仍要靠你用断点和日志去验证。换句话说，AI放大的是基本功的杠杆，而不是替代基本功本身。把“读日志、打断点、补打印”这套童子功练扎实，无论工具如何进化，你都能在最短的时间里，把程序从“不对劲”拽回“能运行”。