Long Task 是持续≥50ms的主线程任务，是卡顿、响应延迟、掉帧主因；需在Performance面板中通过黄色长条识别，结合调用栈定位函数，按计算型、DOM触发型、渲染阻塞型、第三方脚本型分类优化。
直接看 Performance 面板里的黄色长条——超过 50ms 的主线程任务就是 Long Task，它是页面卡顿、响应延迟、动画掉帧的最常见根源。
在 Performance 面板中识别长任务
打开目标网页后，按 F12 → Performance → 勾选 Screenshots 和 Memory → 点击录制按钮（●）→ 刷新页面 → 停止录制。录制完成后，展开 Main 轨道，注意以下特征：
- 所有持续时间 ≥ 50ms 的任务块会被标为亮黄色，连续密集的黄条说明主线程长期被占用
- 鼠标悬停任意黄条，右侧 Summary 会显示总耗时、调用栈和子任务分类（Script / Layout / Paint 等）
- 点击黄条右侧的 ▼ 展开调用栈，逐层下钻，最终定位到具体函数名、文件路径和行号
- 重点关注 Function Call 中耗时占比最高的函数，比如
renderList、calculateData或第三方 SDK 的初始化方法
区分长任务的真实成因
不能只看“JS 执行久”，要结合调用栈与上下文判断本质问题：
- 纯计算型：如大数据排序、JSON 解析、循环遍历万级数组——适合移交 Web Worker 或分片执行
-
DOM 触发型：读写交替（如反复查
offsetTop后立刻改style.left），触发强制同步布局——应批量读、批量写，或改用transform -
渲染阻塞型：首屏渲染前执行大量 JS，阻塞 HTML 解析与样式计算——需拆分非关键逻辑，延迟加载或
requestIdleCallback调度 - 第三方脚本型：埋点 SDK、广告代码、统计工具在 onload 后仍持续运行——检查其文档是否支持异步/懒加载，或限制执行时机
验证优化是否生效
改完代码后，不要只看单次录制结果，要对比三次以上：
- 用 Hard Reload（Ctrl+Shift+R） 强制跳过缓存，排除本地资源干扰
- 开启 CPU Throttling（如 4x slowdown） 模拟中低端设备，观察黄条是否显著减少或缩短
- 关注 FPS 曲线是否稳定在 60fps 附近，红色掉帧标记是否消失
- 若仍存在长任务，导出 .json 录制文件，用 Chrome DevTools 的 Performance Insights 自动诊断建议
长任务不是“慢”，而是“占着主线程不放”。定位它靠面板，修复它靠拆解、移出或延后——50ms 是硬门槛，不是建议值。
