Performance Timeline虽不直接标注宏/微任务，但可通过任务形状、位置、时长及Call Tree等线索人工识别：宏任务为独立黄色/红色块（≥4ms），微任务为嵌套在宏任务末尾的≤1ms灰色/浅蓝小段；结合PerformanceObserver打标与高级追踪选项可精准定位卡顿根源。

浏览器 Performance Timeline 本身不直接标注“宏任务”或“微任务”标签，但可以通过任务类型、执行位置、时间特征和上下文线索精准识别并定位它们引发的耗时卡顿。关键不是靠自动分类，而是结合事件循环规律与面板可视化信号做人工判读。

看任务在主线程（Main）轨道中的位置和形状

宏任务通常表现为独立、稍长（≥4ms）、前后有空隙的黄色/红色块，比如：

• setTimeout/setInterval 回调：出现在宏任务队列轮到它时，常紧接在一次渲染或用户事件之后，且起始位置不贴着上一个任务末尾（因要等微任务清空）
• UI 事件回调（click、scroll）：触发时机明确，但若内部含同步计算或强制 layout，会拉长该块持续时间
• requestAnimationFrame 回调：固定出现在每帧渲染前约 16ms 周期点，若某次执行超时（如 >10ms），就构成微观卡顿

微任务不会单独成块，而是嵌套在宏任务末尾的紧凑灰色/浅蓝小段中，常紧贴在同步代码或 Promise 创建之后，长度通常 ≤1ms。如果看到一段极短但密集的连续执行（如多个 .then() 连续触发），基本就是微任务队列被清空的过程。

用 Call Tree 和 Self Time 找真实瓶颈

单击 Main 轨道中的任一任务块 → 查看下方 Call Tree → 按 “Self Time” 降序排列：

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• 若顶层函数是 PromiseResolveThenHandler 或 MutationCallback，说明这是微任务执行体；耗时高意味着 Promise 链里有同步重逻辑（如大数组遍历、正则匹配）
• 若顶层是 TimerFire 或 EventListenerHandler，属于宏任务；耗时超标（如 >15ms）就说明这个 setTimeout 或事件处理函数本身太重
• 出现 Recalculate Style 或 Layout 在微任务内？那是典型反模式——比如在 Promise.then 里读取 offsetHeight，会强制同步触发回流

开启高级追踪选项增强辨识度

录制前在 Performance 面板勾选这些选项：

• Screenshots：对齐视觉卡顿与任务块，确认是否因宏任务挤占了帧预算（如某帧没来得及 Paint）
• Web Vitals：标记 CLS（布局偏移）、LCP（最大内容绘制）等指标，间接反映微任务中 DOM 修改是否引发意外重排
• Memory：配合查看微任务高频触发是否伴随锯齿状内存分配脉冲（如每个 Promise.then 都新建对象）
• Event Log：开启后能看到 microtask 和 timer 类型事件的时间戳，辅助验证执行顺序

用 PerformanceObserver 主动打标关键节点

光靠录制被动观察不够，需在代码中主动埋点：

• 在关键宏任务入口加 performance.mark('macro-start')，出口加 performance.mark('macro-end')
• 在 Promise 链开头/结尾或 queueMicrotask 内部也打 mark，再用 performance.measure() 计算区间耗时
• 录制后在 Performance 面板的 Timings 轨道中查看这些自定义 mark，就能把抽象的“微任务执行”映射到具体时间轴上

这样既避开浏览器不标注的限制，又让 Timeline 真实反映你关心的任务边界。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南