debugging

Debugging

概述

用科学方法定位 bug 的根因，而不是凭直觉乱改碰运气。核心：调试是观察 → 假设 → 设计实验验证 → 缩小范围 → 定位根因的循环，每一步都有依据。改到"不报错"不算修好——那可能只是把症状盖住了，根因还在。

何时使用

• 遇到报错/崩溃/行为异常，要定位原因
• bug 不稳定复现，不知触发条件
• 调试卡住、改了好几处都不行
• 看了代码"没发现问题"，但程序确实有问题

不该用：行为符合预期的"不是 bug"（先确认是不是 bug，别把功能当 bug 调）；环境/部署问题（先排查是不是代码外原因）。

与相邻 skill 的边界：debugging 管定位根因（调查：复现、假设、二分、读堆栈），verify-and-fix 管修复与验证（改对：修病因不症状、防回归）。两者接力——debugging 找出"问题是什么、在哪"，verify-and-fix 接手"怎么改对、怎么确认修好"。debugging 的终点（定位的根因）就是 verify-and-fix 的起点。

当 bug 报告太模糊时（"页面打不开""功能不工作"却没给报错/复现步骤），先回到 clarifying-questions 的思路——要可观察的现象（报错信息、触发操作、环境、是所有情况还是特定情况）再分析。没有现象的调试就是盲猜。

核心内容

第一原则：先看报错，别跳过它直接猜

报错信息（异常类型、消息、堆栈、行号）往往直接包含根因线索，是调试最便宜的情报。最常见、最浪费的错法是不看报错就凭直觉改——明明堆栈第 3 行写着 Cannot read 'id' of undefined at line 42，却跳过它去猜"是不是网络问题""是不是缓存"。

读报错的顺序：

1. 异常类型 + 消息：发生了什么（TypeError？NullPointer？超时？）
2. 第一个你自己代码的堆栈帧：在哪发生的（行号 + 函数）——注意是"你的代码"，不是框架/库内部的帧
3. 触发上下文：什么操作/数据触发的

读堆栈的技巧：堆栈常被框架/异步包装得很难读，几个技巧帮你找到真正的根因帧：

• 跳过框架帧：堆栈顶部往往是一堆框架内部代码（React 调度、Express 中间件、ORM 反射），真正的根因在第一个属于你项目源码的帧——往下翻找到你认识的文件名/行号。
• 异步代码的堆栈可能不连续：async/await、Promise、回调、事件循环的堆栈经常断开（一个错误在 setTimeout 里抛，堆栈却看不到触发它的代码）。现代运行时有 --async-stack-traces 或类似的异步堆栈支持，开启它；否则要在触发处手动打日志补全调用链。
• 错误被转发后原始堆栈会丢：如果错误被 catch 又重新抛（尤其改了消息或包了新异常），原始堆栈可能藏在 error.cause 或 originalError 里——别只看最外层，挖嵌套的 cause 链。

养成习惯：遇到 bug，第一件事是完整读一遍报错，而不是打开编辑器开始改。读不懂报错时，先查懂它（搜异常类型、读文档），别跳过。

先复现，再调试

不能稳定复现的 bug 几乎无法调试——你改了不知道有没有效，因为"不报错"可能是修好了，也可能是这次没触发。调试前先建立可复现：

• 找到触发 bug 的最小条件：什么输入、什么操作顺序、什么状态组合下必现？
• 最小化：剥离无关因素，直到只剩"做 X 就必崩"。最小复现让你能反复试验、验证修复。

不稳定复现的 bug（偶发）尤其要先攻克复现——它通常意味着有隐含条件没找到（并发时序、特定数据、资源竞争、时间相关）。找这个条件本身就是定位根因的关键。

反例：bug 偶发，你直接多加几个 try/catch 把可能出错的地方包起来"这样就不崩了"——错误被吞了看不见，但触发条件和根因一行没动，换个场景又炸，而且现在连报错都没了，更难查。

科学方法：假设 → 实验 → 验证

定位根因靠假设驱动，不是碰运气：

1. 观察：报错是什么、何时发生、复现条件。
2. 假设："我猜根因是 X"——基于观察和代码理解提出具体、可证伪的假设（不是"大概是哪里有问题"）。
3. 设计实验：如果是 X 导致的，那应该观察到 Y（可验证的预测）。
4. 验证：跑实验，看 Y 是否成立。成立 → 假设支持，继续深入；不成立 → 排除这个假设，换下一个。
5. 缩小范围：每次实验排除一部分可能性，把根因锁定在更小的范围。