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 的属性，但堆栈往往只指向出错行，不告诉你前面哪步丢了值。实际排查顺序应该是：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

立即学习“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()，否则错误会静默丢失

异步错误最麻烦的不是报错本身，而是你以为它被处理了，其实早就沉底了。