调试与错误定位

学习目标

这一课练习「有方法地找 bug」：用断点代替盲猜，用调用栈定位出错函数，用网络记录区分前端和接口的责任，最后把问题压缩成最小复现（minimal reproduction，能触发问题的最短代码）并写成合格的缺陷描述。读完你应该能独立排查一个「不知道哪坏了」的问题。

问题场景

测试同学报来一个 bug：「点收藏按钮，列表有时候不刷新」。你盯着代码看了十分钟没头绪，加了一堆 console.log 又把控制台刷满。低效的根源是「用眼睛扫代码」——调试的正路是让程序停下来，在出错现场看每个变量的值和到达现场的路径。

核心解释

三个工具按顺序上：

1. 断点（breakpoint）：在开发者工具的 Sources/调试器面板点行号，程序跑到那行会暂停，此时能看所有变量的实时值、逐行执行（单步）。比 console.log 强在：不用改代码、不用重跑、能看到完整现场。
2. 调用栈（call stack，从出错点回溯到入口的函数调用路径）：报错第一行给出位置，栈的每一层告诉你「谁调用了谁」。从上往下读，找到第一个属于自己代码的帧，那里通常是动手的起点。

TypeError: Cannot read properties of undefined (reading 'title')
    at CourseCard (CourseCard.jsx:12)
    at renderWithHooks (react-dom.js:16305)
    at mountIndeterminateComponent (react-dom.js:20074)

3. Network 记录：界面数据不对时先分层——请求发出去了吗？状态码对吗？响应内容对吗？接口返回的数据本身就错的话，前端写得再对也没用；这一步把「前端 bug」和「接口 bug」切开。

示例拆解

一份完整的排查记录长这样，注意每一步都留下证据：

1. 复现：点收藏按钮，10 次里约 3 次列表不刷新
2. 断点：在 toggleFavorite 的 setList 处暂停
3. 观察：不刷新时 setList 收到的还是旧数组——旧请求后到，覆盖了新结果（竞态）
4. 结论：点太快时两次请求并发，先发的后到
5. 修复方向：请求加 AbortController，新请求发出前取消旧请求（见 F10）

最小复现是把问题「剥到最瘦」：新建一个空 HTML，只留会出错的那几行。剥的过程本身就是定位——剥到哪一步问题消失，原因就在刚剥掉的那块里。写缺陷报告时把证据带上：输入了什么、期望什么、实际什么、环境（浏览器与版本、系统、账号状态），外加复现步骤和最小复现代码。验收标准只有一条：别人照着能复现。

动手任务

本课没有在线实验，用本机任意自己的页面（或前面课程的实验文件）练：

1. 在代码里找一个事件回调，给它设断点，单步执行三行，把每步的关键变量值记下来。
2. 故意制造一个 TypeError（访问 undefined.title），从控制台报错点进 Sources，练习「报错 → 调用栈 → 自己代码那一帧」的定位路径。
3. 打开 Network 面板找一个接口请求，依次读出请求 URL、状态码、响应前 100 个字符；假设它是脏数据，写出你会先查前端还是先找后端，为什么。

常见错误

• console.log 满天飞：改代码、重跑、翻日志三倍耗时；能设断点的场景一律断点。
• 只读报错第一行不看调用栈：第一行是「死在哪」，调用栈才是「怎么死的」。
• 跳过复现直接改代码：改完不知道修没修好，因为没有稳定的复现路径可以验证；先让 bug 稳定出现，再动手。
• 缺陷报告只写「页面坏了」：缺输入、缺环境、缺复现步骤，队友只能从头查一遍。

检查与复盘

完成下方检查题确认理解。自查清单：

• 会设断点、单步执行、读调用栈，并能找到自己代码的那一帧
• 数据类问题先用 Network 面板切分前端与接口的责任
• 最近的缺陷报告包含输入、期望、实际、环境和复现步骤

参考资料

• Chrome DevTools：调试 JavaScript —— 断点与单步的官方指南
• Firefox 开发者工具：调试器 —— Firefox 下的对应功能
• MDN：Console API —— console 各方法的正确用法