如何利用 Chrome DevTools 帧记录精确找出长列表滚动卡顿的根源？

本文共计817个文字，预计阅读时间需要4分钟。

直接卡在点一下就录中，无法录制到真实瓶盖问题。滚动是持续事件，必须让DevTools捕获完整的交互周期：

不这么做，容易漏掉 _move 或 requestAnimationFrame 中的短时高频任务；CPU 节流不开，长任务可能压根不显红，误判“没瓶颈”。

在火焰图里盯住 Main 线程的红色长任务

停止录制后，展开 Main 线程轨道，垂直扫描所有标红的长条（Chrome 标记为 Long Task >50ms）。这不是看“哪段 JS 名字长”，而是聚焦三类典型阻塞源：

• Recalculate Style 和 Layout 高频出现 → 说明滚动中反复读写 offsetHeight、getBoundingClientRect() 或触发强制同步布局
• 堆栈里含 _translate、scrollerStyle.transform 但耗时突增 → 很可能 CSS 层面用了 transition: all 或未启用 will-change: transform
• 函数名含 render、update、diff 且持续 >30ms → 虚拟列表未生效，或组件在滚动中做了非必要状态更新（比如监听了 scroll 事件却没节流）

用 Summary 面板交叉验证 FPS 与渲染阶段耗时

顶部 Summary 面板不是摆设。拖选一段明显卡顿的帧区间（FPS 图表里变红/掉到 40 以下的区域），看右侧耗时分布：

• 若 Rendering 占比超 40%，重点查 Paint 和 Composite Layers —— 可能是大量 SVG 图标（如 IconPark）或未 contain: paint 的容器导致重绘面积过大
• 若 Scripting + Rendering 合计超 70%，说明 JS 执行和样式计算/布局形成恶性循环，常见于 iScroll 的 _move 中混入 DOM 查询或 Vue/React 的响应式 getter 触发过多依赖收集
• Idle 时间极少甚至为 0 → 主线程被填满，必须拆分逻辑，别指望靠“优化单个函数”解决

回溯 Detached DOM 或内存泄漏线索

滚动卡顿有时不是当前帧的问题，而是前序操作埋的雷。切换到 Memory 面板，拍两次堆快照：一次在滚动前，一次在反复滚动 10 轮后。对比时重点关注：

• (detached DOM tree) 数量是否持续增长 → 比如 Framework7 的 nextTick 回调里创建了未销毁的事件监听器或定时器
• JS heap size 曲线是否阶梯式上升 → 长列表中每个 item 绑定了闭包引用了外部大对象（如整个 data 数组），导致无法 GC
• 搜索关键词 iScroll 或 scroller，看实例是否意外残留多个 → 常见于组件销毁时没调用 myScroll.destroy()

滚动本身不分配新内存，但错误的生命周期管理会让每次滚动都加重负担，最终在某次触发 GC 时突然卡住一帧——这种问题只看 Performance 面板会漏掉。