核心是启用异步堆栈追踪并精准设断点：勾选“Enable async stack traces”，在await行或.then回调首行设断点，通过Call Stack中的“Async call from”标记、Scope面板变量值及Network面板请求详情综合验证。
Chrome DevTools 调试异步代码，核心不是“能不能停”，而是“停得准、看得清、跟得全”。关键在于让调试器理解 Promise 和 async/await 的执行边界，而不是靠反复刷新或插 console.log 猜。
开启异步堆栈追踪
这是所有异步调试的前提。没有它，Call Stack 里只显示当前回调，看不到是谁发起的 Promise。
- 打开 Sources 面板 → 右上角三个点 → Settings → Preferences
- 勾选 Enable async stack traces
- 刷新页面后，断点命中时 Call Stack 中会出现 “Async call from” 分隔线，以及带 async function 或 Promise.then 的完整链路
在正确位置设断点
断点位置错了，再强的工具也白搭。重点盯住“暂停-恢复”的交接点：
-
async/await 场景：在
await fetch(...)这一行设断点（不是 await 后面那行），能观察 promise 状态、检查请求参数 -
Promise 链场景：在
.then(response => { ... })的大括号第一行设断点，避免跳过入口直接进函数体 - 事件驱动场景：在 Elements 面板选中按钮 → 右侧 Event Listeners → 展开 click → 点击函数链接跳转源码并设断点
结合调用栈与作用域验证状态
断点停住后别急着点“继续”，先看三处：
- Call Stack：确认有 “Async call from” 标记，说明异步链已生效；若只有匿名函数或 setTimeout，说明异步堆栈未启用或当前是宏任务
-
Scope 面板：查看 await 前后的变量值是否符合预期，比如
url是否拼写错误、response是否为 undefined - Network 面板：右键对应请求 → “Reveal in Network”，核对状态码、响应数据结构、时间线，确认问题出在 JS 逻辑还是服务端返回
避开常见盲区
有些情况异步堆栈不生效，提前知道能少绕弯：
-
setTimeout/setInterval 不受异步堆栈支持：它们属于宏任务，需依赖普通断点或用
performance.now()手动打点比对时间 - Source Map 未加载时断点失效：尤其在 Webpack/Vite 项目中，确保 Settings → Preferences → “Enable JavaScript source maps” 已勾选
- debugger; 语句不触发：检查 DevTools 是否已打开；若页面启用了 CSP 且不含 'unsafe-eval'，动态注入的脚本中 debugger 会被静默忽略
