准确定位真实阻塞点需结合火焰图中main线程红色长任务与fps、渲染阶段占比交叉验证；performance录制须滚动至少1秒、开启4x cpu节流；重点关注recalculate style/layout、transform耗时突增、render/update/diff超30ms三类问题；summary面板验证rendering或scripting占比异常；memory查内存泄漏；network勾选disable cache和限速排查加载阻塞。
直接看火焰图里 Main 线程的红色长任务，再结合 FPS 和渲染阶段占比交叉验证，就能准确定位真实阻塞点。
Performance 面板要这样录才有效
不能点一下就停——滚动类问题必须快速、多次、贯穿整个列表滚动至少 1 秒以上；CPU 节流必须开（推荐 4x），否则短时高频任务压根不显红，容易误判“没瓶颈”。操作流程是：F12 → Performance → 勾选 CPU Throttling（4x）→ 点红点开始 → 立即滚动 → 滚完再点停止。
火焰图里盯这三类红色长任务
不是看函数名长短，而是聚焦实际影响渲染的典型行为：
- Recalculate Style 或 Layout 高频出现 → 很可能在滚动中反复读取 offsetHeight、getBoundingClientRect()，触发强制同步布局
- 堆栈含 _translate 或 scrollerStyle.transform 但耗时突增 → CSS 层面用了
transition: all或没加will-change: transform - 函数名含 render、update、diff 且单次持续 >30ms → 虚拟列表失效，或 scroll 事件监听器没节流，导致滚动中频繁重绘
用 Summary 面板验证卡顿是否真由渲染拖累
拖选 FPS 明显掉到 40 以下的帧区间，看右侧耗时分布：
- 若 Rendering 占比异常高（比如超 40%），说明样式计算、布局或绘制本身吃资源
- 若 Scripting 占比高且对应长任务堆栈清晰，说明 JS 执行拖慢了帧生成
- 顺便扫一眼 Memory 面板，查 detached DOM 节点或内存持续上涨，排除隐性泄漏干扰
Network 面板辅助排查加载期阻塞
刷新前务必勾选 Disable cache 和 Fast 3G（或自定义限速），重点看瀑布图里：
- 浅色部分（blocked/dns/connect）过长 → 服务端响应慢或 DNS/TCP 建连有问题
- 深色下载块横向太宽 → 资源体积大，需压缩或懒加载
- 后续请求被明显推迟 → 存在不合理依赖，比如关键 JS 阻塞了字体或图片加载
