chrome performance 面板虽不直接显示 async/await 调用栈，但能通过 scripting 块与微任务标记揭示其真实执行节奏，并联动 sources 面板启用异步堆栈追踪，精准定位 await 行为、性能瓶颈及未捕获错误。
Chrome Performance 面板本身不直接显示 async/await 的调用栈，但它能与 Sources 面板的异步堆栈追踪能力协同工作，把“代码逻辑”和“执行时序”对齐起来——这才是分析 async/await 行为的关键视角。
看清 await 的实际执行节奏
async/await 看似同步写法，实则依赖微任务调度。Performance 面板能直观暴露它在事件循环中的真实位置：
- 录制用户操作（如点击触发一个 async 函数），在 Main 轨道中查找黄色 Scripting 块：await 表达式本身几乎不耗时（只创建 Promise 并返回），真正的后续逻辑会出现在下一个微任务块里
- 观察两个 Scripting 块之间是否夹着绿色微任务标记（如 Promise.then）；若中间还穿插了其他微任务，说明存在未 await 的 Promise 链或意外的 queueMicrotask
- 鼠标悬停微任务块，Summary 区会显示 “initiated by fetch” 或 “initiated by async function”，帮你确认源头是否符合预期
识别 await 使用不当引发的性能问题
滥用 await 会导致本可并行的操作被强制串行，Performance 面板能量化这种损耗：
- 对比两段逻辑：一段用 await 依次调用三个独立 API，另一段用 Promise.all 并发发起——前者在 Main 轨道上呈现为三个明显分隔的 Scripting 块，总耗时接近三者之和；后者则基本重叠，总耗时接近最慢那个请求
- 若发现某段 async 函数内部出现多个连续、短小的黄色块（每个
- 长任务（标红 >50ms）若出现在 await 后的处理逻辑中（如大量数据 map/filter），说明瓶颈不在异步等待，而在同步计算阶段，需单独优化
联动 Sources 面板验证异步上下文
Performance 定位到可疑时段后，必须回到 Sources 面板才能看懂“是谁、在哪、为什么”：
- 在 Performance 的 Main 轨道中右键点击某个微任务 Scripting 块 → 选择 “Reveal in Sources”，DevTools 会自动跳转到对应 async 函数或 .then 回调的源码行
- 此时确保已开启 “Enable async stack traces”，Call Stack 中会出现灰色 Async 标签，点击即可回溯到原始触发点（比如某个按钮的 click 事件处理器）
- 结合 Scope 面板检查该时刻变量值：await 前的参数是否正确？await 后拿到的响应数据结构是否与预期一致？避免因数据格式错误导致后续逻辑反复重试或阻塞
配合 unhandledrejection 和错误堆栈交叉验证
async/await 错误若未被捕获，会在 Performance 中表现为突然中断的 Scripting 块，同时伴随 unhandledrejection 事件：
- 开启 Performance 录制时，勾选 “Screenshots” 和 “Disable cache”，更容易复现偶发错误
- 停止录制后，在 Summary 区筛选 “Errors”，查看是否有 unhandledrejection 条目；点击可跳转到 Console，那里会显示带完整异步堆栈的错误信息
- 若错误堆栈只到 async 函数入口就断开，说明 “Enable async stack traces” 未启用，需返回 Settings 补开
