Chrome DevTools断点调试应按需选用：普通行断点查逻辑执行，条件断点避循环停顿，XHR/fetch断点捕获异常请求，DOM断点定位非法修改；辅以console.trace()、console.table()和debugger提升排查效率。
Chrome DevTools 断点调试最常用操作
直接在源码行号左侧点击就能打断点，刷新页面后执行到那行会自动暂停。关键不是“加断点”，而是知道什么时候该用哪种断点：
-
普通行断点：适合确认某段逻辑是否执行、变量值是否符合预期 -
条件断点（右键行号 → “Edit breakpoint”）：填入i === 100这类表达式，避免循环里反复停住 -
XHR/fetch 断点（Network tab → “XHR/fetch breakpoints”）：当接口调用异常但没报错时，能抓到请求发出前的调用栈 -
DOM 断点（Elements tab → 右键元素 → “Break on”）：页面莫名被改写 DOM 时，立刻定位修改源头
console.log 不够用？换这三种更准的方式
console.log 容易淹没在日志里，且看不出调用上下文。真要排查，优先用：
-
console.trace()：直接打出当前执行位置的完整调用栈，比翻堆栈面板快 -
console.table(data)：查数组或对象结构时，比console.log清晰十倍，尤其适合对比前后状态 -
debugger语句：写在代码里，等效于手动打行断点，适合 CI 环境或无法开 DevTools 的场景（注意上线前删掉）
别对 console.log 有执念——它只是起点，不是终点。
Uncaught TypeError: Cannot read property 'xxx' of undefined 怎么快速定位？
这类错误本质是访问了 undefined 的属性，但堆栈往往只指向出错行，不告诉你前面哪步丢了值。实际排查顺序应该是：
立即学习“Java免费学习笔记（深入）”；
- 看报错行，用鼠标悬停或
console.log检查链式调用中**每一段**是否为undefined，比如a.b.c.d要分别验a、a.b、a.b.c - 启用 Chrome 的
Pause on caught exceptions（Sources tab 右上角三个点 → Settings → “Pause on caught exceptions”），很多“静默失败”其实是被try/catch吞了，打开后能捕获到原始抛出处 - 用可选链操作符
?.替代点号（如a?.b?.c），既防错又自带线索：哪个?生效了，就说明前面是undefined
async/await 错误为什么总找不到源头？
Promise 链里的错误堆栈常被截断，await 后的报错看起来像发生在顶层。核心解决法就两条：
- 所有
await调用必须配try/catch，不要依赖外层catch—— 尤其是多个await连续写时，第一个失败就会中断后续，但错误堆栈未必指向它 - 在
chrome://flags/#enable-javascript-stack-trace-on-async-tasks开启实验性异步堆栈追踪（Chrome 120+ 默认开启），能让await报错带上完整的异步调用路径 - 用
Promise.catch(() => {})替代.then().catch()链时，记得返回Promise.reject()，否则错误会静默丢失
异步错误最麻烦的不是报错本身，而是你以为它被处理了，其实早就沉底了。
