Chrome DevTools断点调试应按需选用：普通行断点查逻辑执行，条件断点避循环停顿，XHR/fetch断点捕获异常请求，DOM断点定位非法修改；辅以console.trace()、console.table()和debugger提升排查效率。
直接在源码行号左侧点击就能打断点，刷新页面后执行到那行会自动暂停。关键不是“加断点”，而是知道什么时候该用哪种断点：
普通行断点：适合确认某段逻辑是否执行、变量值是否符合预期条件断点（右键行号 → “Edit breakpoint”）：填入 i === 100 这类表达式，避免循环里反复停住XHR/fetch 断点（Network tab → “XHR/fetch breakpoints”）：当接口调用异常但没报错时，能抓到请求发出前的调用栈
DOM 断点（Elements tab → 右键元素 → “Break on”）：页面莫名被改写 DOM 时，立刻定位修改源头console.log 容易淹没在日志里，且看不出调用上下文。真要排查，优先用：
console.trace()：直接打出当前执行位置的完整调用栈，比翻堆栈面板快console.table(data)：查数组或对象结构时，比 cons
ole.log 清晰十倍，尤其适合对比前后状态
debugger 语句：写在代码里，等效于手动打行断点，适合 CI 环境或无法开 DevTools 的场景（注意上线前删掉）别对 console.log 有执念——它只是起点，不是终点。
这类错误本质是访问了 undefined 的属性，但堆栈往往只指向出错行，不告诉你前面哪步丢了值。实际排查顺序应该是：
console.log 检查链式调用中**每一段**是否为 undefined，比如 a.b.c.d 要分别验 a、a.b、a.b.c
Pause on caught exceptions（Sources tab 右上角三个点 → Settings → “Pause on caught exceptions”），很多“静默失败”其实是被 try/catch 吞了，打开后能捕获到原始抛出处?. 替代点号（如 a?.b?.c），既防错又自带线索：哪个 ? 生效了，就说明前面是 undefined
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()，否则错误会静默丢失异步错误最麻烦的不是报错本身，而是你以为它被处理了，其实早就沉底了。