页面交互卡顿、掉帧严重怎么排查？
目前顯示中文（中國）原文
视频笔记：《前端面试官：页面交互卡顿、掉帧严重怎么排查？》，UP 主「Web前端面试题」，时长约 4 分 16 秒。依据视频画面与内嵌字幕整理；下文另行标明技术校正和实操补充。
核心结论
卡顿排查的重点，是拿到异常交互的性能记录，确定时间消耗在什么阶段，找到具体调用和触发原因，再用同一场景验证修复效果。防抖、节流、虚拟列表、Web Worker 各有适用条件，应该由性能证据决定使用哪一种。
视频用四层展开这条主线：理解一帧的工作、正确录制和阅读 Performance、按耗时类型定位瓶颈、针对瓶颈修复。
第一层：先理解一帧的预算
浏览器更新画面时，可能涉及 JavaScript、样式计算、布局、绘制、栅格化和合成。不同变更触发的阶段不同，也不是所有阶段都在主线程上执行。
- 60 Hz 屏幕的刷新间隔约为 16.7 ms，120 Hz 约为 8.3 ms。这是一帧的总时间尺度，业务 JavaScript 能使用的时间还要给其他工作留余量。
- 主线程被长时间占用，或者布局、绘制、栅格化等阶段未能及时完成，都可能让画面错过刷新时机。
- Long Task 的阈值是任务持续超过 50 ms，和帧预算不是同一个概念。 即使没有 Long Task，多个较短任务或昂贵的渲染工作也可能造成掉帧。
因此，“JS 只执行了 2 ms，但页面仍掉帧”完全可能。下一步应检查布局、绘制、栅格化、合成及线程调度，而不是直接认定 DOM 太多。
第二层：用 Performance 把问题缩小到一个时间段
视频强调先找异常帧，再看 Main 主线程和耗时构成。实操时可以按下面的顺序进行：
- 固定复现条件。 明确是输入、点击、滚动、拖拽还是动画卡顿，记录设备、浏览器和数据量。使用接近线上环境的构建；需要 CPU 降速时，前后使用相同设置。
- 录制一次短而完整的交互。 打开 Chrome DevTools 的 Performance，开始录制，执行问题操作，结束录制。避免把大量无关空闲时间混在一起。
- 找异常区间。 结合 Frames、交互轨道和截图检查停顿位置；查看版本中可用的丢帧标记与长任务警告，再缩小时间范围。
- 分解这段时间。 查看 Main 线程中的脚本、样式计算、Layout、Paint 等事件；需要时继续查看 Raster、合成和 GPU 相关轨道。选中范围后的 Summary 能帮助判断主要时间花在哪里。
- 落到调用与代码。 用 Call tree 看调用关系，用 Bottom-up 找累计耗时较高的函数，区分自身耗时和包含子调用的总耗时，再定位源码或触发更新的位置。
火焰图横向宽度表示持续时间，但父函数可能只是包含了昂贵的子调用。找到最长的条只是线索，还需要向下追踪真正消耗时间的工作。
第三层：按证据区分瓶颈
| 主要耗时或现象 | 重点检查 | 常见修复方向 |
|---|---|---|
| Scripting 较高 | 长循环、大 JSON 解析、复杂正则、重复计算、过量框架更新 | 减少工作量、缓存合适的结果、拆分任务、将合适的计算移到 Worker |
| 样式计算或 Layout 较高 | DOM 规模、反复布局、修改样式后读取几何信息、过大更新范围 | 虚拟列表、批量处理 DOM 读写、缩小更新和布局影响范围 |
| Paint 或栅格化较高 | 重绘区域、昂贵阴影和滤镜、滚动时反复重绘大块内容 | 减少重绘面积与效果成本，检查图片尺寸和栅格工作 |
| 合成相关工作较高 | 图层数量、巨大纹理、频繁图层变化、GPU 和显存压力 | 精简图层，控制纹理与动画成本，核查图层提升是否有收益 |
| System／其他耗时较高 | 具体事件、线程、垃圾回收和环境负载 | 先明确来源，区分页面造成的开销和系统竞争，再决定修复位置 |
强制同步布局要看具体读写顺序
例如，循环中每次修改元素宽度，随后立即读取 offsetWidth，可能迫使浏览器提前完成布局；反复交错这种读写，会形成布局抖动。
改进方向是先批量读取所需几何信息，再批量写入样式，并去掉不必要的同步测量。读取 offsetTop 本身不等于一定发生重排，关键在于读取时布局是否已经失效，以及浏览器是否必须立即计算结果。
框架更新也要回到实际工作量
如果 trace 指向组件更新，再结合 React 或 Vue 的性能工具判断哪些组件反复更新、更新范围是否过大。只有发现相应开销后，才考虑状态下沉、稳定属性、记忆化等措施。
第四层：修复方案要匹配瓶颈
脚本阻塞： 优先减少计算和重复更新。需要分片时应让主线程有机会处理输入和渲染；把同样的重计算塞进 Promise 微任务，并不能保证让出渲染机会。Web Worker 适合可移出主线程的计算，不能直接操作 DOM，还要考虑消息传递和数据复制成本。requestIdleCallback 适合可延后的后台工作，不能保证关键交互及时完成。
布局开销： 大列表可以考虑虚拟滚动，同时保留合理的滚动、焦点和无障碍体验；减少 DOM 读写交错，缩小更新范围。动画优先评估 transform、opacity，并用录制结果确认是否避免了不必要的布局或绘制。
绘制和合成开销： 减少大范围重绘和昂贵视觉效果。will-change 应只用于少量确有收益的元素，并在不需要时移除；大量提升图层会增加内存和合成成本。contain 可帮助隔离影响范围，但不同取值会改变布局、尺寸或裁剪行为，使用前要确认页面仍然正确。
对视频中几处表述的校正
- 颜色和时间阈值： 视频提到“超过 50 ms 标黄、超过 90 ms 标红”。这不能作为通用的 DevTools 判定规则；轨道颜色、警告和界面会随版本与事件类型变化，应以具体事件名称、持续时间和警告说明为准。50 ms 的 Long Task 阈值也不代表 50 ms 以内就流畅。
- System 归因： System 占比高，不能直接推导为“与代码无关”。需要继续展开事件和相关线程，检查页面分配、垃圾回收、浏览器内部工作及系统资源竞争。
- 合成优化： 使用
transform不保证任何场景都“只走合成”，也不保证必然更快。图层、栅格化、纹理和运行环境都会影响结果；优化结论应由实际 trace 支持。
实操补充：用同场景验证修复
保持设备、数据、构建和录制条件一致，重新执行同一个交互，比较输入响应、异常帧、长任务次数与时长，以及目标阶段的耗时。重复几次确认收益稳定，同时检查滚动、动画、内存和操作行为是否出现退化。
掉帧和交互延迟有关，但指标并不等价。INP 主要衡量点击、轻触、键盘等交互的响应，滚动和持续动画还需要结合帧时间观察；也不能用一次本地录制直接声称线上 INP 已改善。
面试回答示例
我会先明确是哪种交互卡顿，在固定设备和数据条件下，用 Performance 录制可复现的过程。先找到异常帧或响应延迟区间，再拆解 Main 线程和相关渲染线程的耗时。脚本高就沿调用树定位长任务和重复计算；布局高就查 DOM 规模和强制同步布局；绘制或合成高就看重绘区域、滤镜、图层与栅格化。然后选择任务拆分、Worker、虚拟列表或绘制优化，并用相同条件重新录制验证。60 Hz 下帧间隔约 16.7 ms，Long Task 的 50 ms 阈值是另一个概念，没有长任务也可能掉帧。
关联笔记
- 事件循环、微任务与渲染机会：理解任务调度如何影响渲染机会。
- 节流、防抖与取消待执行任务：判断高频事件应该如何控制执行频率。
- 内存泄漏的快照与引用链排查：跟进持续增长的内存和相关性能问题。
- Fiber 的协作调度与不可中断边界：理解框架调度能处理的范围和限制。