Chrome DevTools 通过异步堆栈追踪、Performance 面板、事件监听器断点、XHR/Fetch 断点和 unhandledrejection 监听，系统化定位异步时序问题。
Chrome DevTools 分析异步事件的调用时序，核心是把“看不见的跳转”变成可追踪、可回溯的时间线。不是靠猜，而是用工具把 Promise.then、setTimeout、fetch 回调、事件监听器这些分散在不同任务队列里的执行点，串成一条清晰的因果链。
开启异步堆栈追踪（Async Call Stack）
这是看清源头的第一步：
- 打开 Sources 面板，任意 JS 文件加载后，右键调用栈区域 → 勾选 Async
- 或进入 Settings → Preferences → Console → 勾选 Enable async stack traces
- 触发异步操作（如点击按钮发起 fetch），断点命中后，调用栈顶部会出现灰色 async 标签（例如
fetch.then → processData → updateUI） - 点击灰色标签，Sources 会自动跳转到该回调函数原始定义位置，哪怕它在另一个模块或 bundle 里
用 Performance 面板看任务排队与执行节奏
时序问题（比如“为什么点了按钮要等 800ms 才渲染？”）得看事件循环实际怎么跑：
- 打开 Performance 面板，勾选 Async stacks 和 Network（可选）
- 点击录制按钮，执行用户操作（如输入、点击、滚动）
- 停止后展开 Main 轨道，关注带颜色的任务块：
- 蓝色：宏任务（setTimeout、I/O 回调、UI 事件）
- 绿色：微任务（Promise.then、queueMicrotask、MutationObserver 回调）
- 鼠标悬停任一任务块，底部 Summary 显示触发源（如 “initiated by click event” 或 “caused by Promise.resolve()”）
- 若发现多个绿色微任务连续堆积 >5ms，或宏任务之间被大量微任务插队，说明 Promise 链过深、await 缺失、或存在未处理的 resolve 循环
结合 Event Listener Breakpoints 定位事件起点
很多异步逻辑由用户事件触发，但你可能不知道谁绑了监听器：
- 打开右侧边栏的 Event Listener Breakpoints
- 展开 Mouse、Keyboard、Network 或 Animation 等分类，勾选具体类型（如
click、input、fetch） - 页面触发对应事件时，执行立即暂停，此时可查看：
- 调用栈中是谁注册了监听器
- Scope 中当前闭包变量状态
- Elements 面板中目标元素的 class、data 属性是否符合预期
用 XHR/Fetch 断点锁定请求上下文
请求发错、参数拼错、token 过期等问题，往往发生在 fetch 调用那一刻：
- Sources → 左侧 XHR/fetch breakpoints → 点 + 号，输入 URL 关键字（如
/api/order）或留空捕获全部 - 当匹配请求发起时，执行暂停，你能立刻看到：
- 是哪个函数、哪行代码调用了 fetch
- 请求前的变量值（比如
userId是否为 undefined） - Network 面板中该请求的完整 headers、payload、发起时间戳
监听 unhandledrejection 补全错误路径
静默失败常因 Promise 拒绝没被捕获，导致后续逻辑中断却不报错：
- 在 Console 中执行：
window.addEventListener('unhandledrejection', e => console.error('Uncaught:', e.reason)); - 如果控制台输出错误，点击堆栈中的文件链接，就能直接跳到那个没加 catch 或 try/catch 的 await 行
不复杂但容易忽略
