DEBUG FLOW
代码调试思路
报错不可怕，可怕的是盯着屏幕瞎改。这一页教你把"改不动"的崩溃，变成"按流程排查"的肌肉记忆。
PROCESS · 通用流程
五步把报错变成修复
调试有标准动作。按这个顺序走，能解决 80% 的问题，剩下 20% 才需要更深的工具。
STEP 01 · 复现
稳定复现 bug
不能稳定复现的 bug 几乎无法修。先找最小复现路径：哪些步骤、哪些数据、哪个环境下必出。
STEP 02 · 隔离
二分法缩小范围
注释掉一半代码看是否还报错，逐步缩小到出问题的具体行。比逐行读快十倍。
STEP 03 · 观察
用断点或日志看真实值
不要靠脑补，要看真实运行时的变量值。80% 的 bug 在你看清变量值的瞬间就明白了。
STEP 04 · 假设
提出根因假设
把"为什么会这样"写成一句话假设，再用断点验证。猜对了再动手改，避免无效修改。
STEP 05 · 验证
修复并回归测试
改完先跑复现路径，再跑一遍完整测试。确认 bug 没了，且没引入新的问题。
DEBUG · 流程
报错是机器在跟你说话，先把它的句子读完
—— 三亩地 · 调试守则
TIP · 读报错
SKILL · 读报错
报错信息的三个关键字
新手看到一长串红字就懵。其实只要抓三个关键字：错误类型、出错文件、出错行号。剩下的多半是调用栈，按需往下读。
// 典型报错示例 TypeError: Cannot read properties of undefined at renderUser (app.js:42) at init (app.js:18) /* 三关键字拆解： 1. 错误类型：TypeError（类型错误） 2. 出错位置：app.js 第 42 行 3. 关键描述：读取 undefined 的属性 → 去第 42 行看，哪个变量是 undefined */
技巧：报错第一行最重要，先看它。第二行起的调用栈，是从出错点往上回溯的执行路径——离出错点最近的通常在最上面。
BISECTION · 二分法
不知道哪里错了？砍一半试试
面对几百行代码不知道哪里出错，二分法是最快的定位手段——每次砍掉一半，看 bug 还在不在。
METHOD · 二分
EXAMPLE · 二分法步骤
四步定位一个隐藏 bug
假设某个页面 200 行代码出问题，按下面四步走，最多四轮就能定位到具体行。
// 第一轮：注释掉后 100 行 // bug 消失 → 问题在后 100 行 // bug 还在 → 问题在前 100 行 // 第二轮：在剩下的 100 行里再砍一半 // 第三轮：剩下 50 行砍成 25 行 // 第四轮：25 行砍成 ~12 行 // 200 行 → 4 轮二分 → 锁定到 ~12 行 // 比一行一行读快 16 倍 console.log('🔍 二分法无敌');
TOOLS · 断点 vs 日志
什么时候打断点，什么时候打日志
两个调试手段各有所长。选错工具会让你事倍功半。
断点 · 适合本地
能逐步执行、查看调用栈、监视变量。适合开发环境排查复杂逻辑，但需要 IDE 支持与可重现的场景。
日志 · 适合线上
记录关键节点的变量值与执行路径。适合无法断点的生产环境，事后翻日志即可复盘。
取舍原则
本地能复现用断点，线上偶发用日志；逻辑复杂用断点，跨服务用日志。开发期多打日志，上线前清理。
调试不是和 bug 拔河，是和它下棋。每一步都要先想"为什么这样改"，而不是"也许这样改就行"。