长任务指浏览器主线程上连续执行超50毫秒的操作，源于rail模型响应目标：为保障100毫秒内用户反馈及渲染、事件等余量，单任务须≤50ms；否则导致交互卡顿、动画掉帧、首屏延迟及耗电加剧。
长任务是指在浏览器主线程上连续执行超过 50 毫秒的 JavaScript 代码块（也包括样式计算、布局、绘制等操作），它会独占主线程，导致页面无法及时响应用户操作或更新 UI。
为什么是 50 毫秒？
这个阈值来自 RAIL 性能模型中的“响应（Response）”目标：用户期望在 100 毫秒内看到操作反馈。但主线程还需处理渲染、事件队列等其他工作，因此把单次任务控制在 50 毫秒内，才能为其余流程留出余量，保障整体响应性。
长任务直接破坏页面流畅度
它不是“慢一点”，而是让浏览器在关键时间窗口里完全失能：
- 交互卡顿：点击、输入、滚动事件被排队等待，用户操作无反馈，出现“按钮点不动”“下拉没反应”等现象
- 动画掉帧：60fps 要求每帧 ≤16ms 完成渲染。一个 80ms 的长任务会直接跳过 4–5 帧，动画明显卡顿、闪烁
- 首屏延迟：阻塞 HTML 解析、DOM 构建和首次绘制（FP/FCP），用户等待时间变长，跳出率上升
- 电池与发热加剧：移动端持续高负载运行，加速耗电，尤其在低端设备上更明显
哪些代码容易触发长任务？
常见诱因不是某一行写得错，而是逻辑堆积在单次调用中：
- 一次性遍历百万级数组做复杂计算（如排序、过滤、格式化）
- 循环中频繁读写 DOM（比如逐个设置 style、反复 querySelector）
- 同步加载或解析大体积 JSON / XML / CSV 数据
- 未节流的 resize / scroll / input 事件监听器密集触发
- 第三方 SDK 在初始化阶段执行大量同步逻辑
它和“卡顿”的关系很直接
卡顿不是主观感受，而是可测量的性能事实——Chrome Performance 面板中 Main 轨道上标红的 >50ms 色块，就是长任务的可视化证据。只要它存在，就说明浏览器在那一瞬间放弃了响应你、放弃了画帧、放弃了滚动平滑性。
