滚动卡顿本质是浏览器无法在16.7ms内完成一帧渲染，核心在于主线程阻塞和合成器线程干扰；需用Firefox Profiler在真实滚动中捕获0.5ms采样数据，聚焦vsync丢帧、长任务及强制同步布局三类瓶颈，并针对性修复iOS滚动配置、DOM读写、虚拟滚动等高频问题。
滚动卡顿本质是浏览器无法在16.7ms内完成一帧渲染，常见于iOS Safari和复杂前端页面。核心要抓住“谁阻塞了主线程”和“谁干扰了合成器线程”两个关键点。
第一步：用工具捕获真实滚动行为
别等页面加载完再点录制——滚动卡顿必须在滚动中抓取数据。
- Firefox用户按 Ctrl+Shift+E（Win/Linux）或 Cmd+Option+E（macOS），直接唤起Profiler；点击“Start recording”后立刻滚动，结束时再按空格键停止
- 采样间隔必须设为 0.5ms（默认1ms会漏掉requestAnimationFrame内的微任务抖动）
- 务必勾选 Screenshots（看丢帧）和 JavaScript samples（查耗时函数），取消勾选Memory（滚动卡顿基本不涉及内存瞬时分配）
- 手动滚动时按住 Shift键，可强制降帧放大卡顿，让问题更易暴露
第二步：聚焦三类典型瓶颈模式
拿到火焰图后，不要从头扫，直奔三处关键区域：
- 帧率曲线底部的红色竖条：代表vsync missed，说明该帧没赶上刷新节奏；拖动时间轴选中一段卡顿区间，右键“Zoom to selection”聚焦分析
- Main轨道里的宽黄色/红色块（≥30ms）：右键“Zoom in on this activity”，再进Call Tree按Self Time排序，排第一的函数就是直接CPU杀手
- Marker Chart中的Layout/Style密集区：如果一次滚动触发5次以上Layout且总耗时超12ms，大概率存在强制同步布局——比如在scroll事件里读offsetHeight又立刻改class
第三步：针对性修复高频诱因
滚动卡顿80%集中在以下几类代码或配置问题：
- iOS Safari必须加 -webkit-overflow-scrolling: touch 到滚动容器，并确保该容器有明确高度（不能是height: auto）和overflow-y: auto
- 避免在scroll、resize等高频回调里做DOM读写操作；用getBoundingClientRect()前先缓存，修改样式优先用transform/opacity，避开触发布局重排
- 长列表务必用虚拟滚动（如react-window）；禁用所有未节流的监听器，尤其IntersectionObserver和ResizeObserver需配合requestIdleCallback使用
- 检查是否意外触发了强制同步布局链：比如先读clientWidth，再改className，再读offsetTop——这类组合会让浏览器反复回流
第四步：验证修复是否生效
改完别只看“好像顺了”，要量化验证：
- 用Chrome DevTools Performance面板录制相同滚动操作，对比FPS曲线是否稳定在55–60fps，Layout耗时是否下降50%以上
- 在Safari iOS真机上打开Web Inspector，启用Rendering面板 → 勾选“Paint Flashing”和“FPS Meter”，滚动时观察绿色闪动是否均匀、右上角FPS数字是否持续高于50
- 若仍偶发卡顿，检查是否有第三方SDK（如统计、埋点、客服组件）在滚动中执行同步脚本，尝试临时移除验证
