关键不是死记报错信息，而是掌握「现象→原因→排查位置」链条：TypeError多因类型错误，ReferenceError因变量未声明，SyntaxError系语法错误；断点后变量异常需查作用域与来源；异步断点失效应启Async追踪并验证调用。
记浏览器断点调试的报错信息，关键不是死记硬背，而是理解错误发生的典型场景和对应位置。JS 断点调试中看到的“报错信息”，其实多数是控制台输出的异常（如 ReferenceError、TypeError），或断点停在某行后变量状态异常（比如 undefined、null、NaN）。真正要记的是「什么现象 → 可能原因 → 去哪查」这个链条。
看控制台报错：先抓关键词，再定位文件行号
Chrome/Firefox 控制台顶部的红色错误行，最前面是错误类型（如 Uncaught TypeError），中间是简短描述（如 Cannot read property 'x' of undefined），最后是文件名和行号（如 script.js:42）。
-
TypeError：几乎都和“值的类型不对”有关——访问了
undefined或null的属性、对非函数执行了()、传了错误类型的参数给内置方法（如JSON.parse(null)） -
ReferenceError：变量根本没声明（
foo is not defined），常见于拼写错误、作用域搞错（比如在函数外用let声明的变量）、模块未导入 -
SyntaxError：代码写错了语法（少括号、多逗号、箭头函数漏
=>），这类错误通常无法进断点，直接报错并中断执行
断点停住后变量异常：重点盯「值」和「作用域」
断点停在某一行，但右侧“Scope”面板里变量显示 undefined、not available 或值明显不对，这时别急着翻报错信息，先做三件事：
- 检查变量是否在当前作用域声明（比如
let在 if 块内声明，断点在块外就看不到） - 看“Watch”里手动加的表达式是否拼错，或用了还未赋值的变量
- 鼠标悬停在变量名上，看提示的值和类型——如果显示
undefined，往上追溯它从哪来（是函数返回值？API 响应？默认值没设？）
异步代码断点失效？优先查调用栈和异步追踪
在 setTimeout、fetch 回调、Promise.then 里打的断点没触发？不是报错，而是没走到那里。这时候要：
- 确认断点所在的函数确实被调用了（可在函数开头加
debugger或console.log） - 打开 Chrome DevTools 的 “Async” 勾选项（在 Sources 面板右上角三个点菜单里），让调用栈显示异步上下文
- 遇到
Promise.catch没捕获到错误？说明错误发生在 Promise 构造函数内部，或被上层try/catch吞掉了——把断点打在reject调用处或throw行更有效
不熟悉报错？善用“重新运行”和“逐步执行”缩小范围
面对陌生错误，与其硬记，不如动手验证：
- 在报错行上方打一个断点，按
F8（继续）或F10（单步跳过）走到出问题那行，观察前一步变量值是否正常 - 右键报错堆栈里的某一行 → “Reveal in file”，直接跳转到源码对应位置（注意 Source Map 是否启用）
- 临时删掉可疑代码（比如注释掉某个对象解构、某个链式调用），看错误是否消失，快速反推问题模块
