直接打开 Chrome DevTools Performance 面板录制操作，掉帧位置在 Main 轨道呈现宽＞16ms 的黄/橙/红块；纵轴为调用栈深度，横轴为时间线；重点关注 Main 长条、FPS 下探区间及 Bottom-Up 中高 Self Time 函数；拖选问题时段、过滤系统脚本、验证耗时与注释测试可精准定位帧杀手。
直接打开 Chrome DevTools 的 Performance 面板，点击录制按钮（●），复现目标操作（比如滚动、点击或动画），停止录制后，火焰图会自动展开——掉帧（60fps 下低于 16.6ms/帧）的位置通常在“Main”轨道上出现明显拉长的黄色或红色块，对应的就是耗时过长的 JS 函数。
看清火焰图的关键区域
火焰图纵轴是调用栈深度，横轴是时间线，每一块代表一个函数执行时段。重点关注三个地方：
- Main 轨道下的长条块：尤其宽度超过 16ms 的黄色（Scripting）、橙色（Rendering）或红色（Painting）矩形，说明该函数单次执行已拖垮一帧
- 顶部 summary 栏的 FPS 曲线：出现明显下探（如掉到 30fps 或更低）的时间点，对齐下方 Main 轨道，就能框定问题区间
- Bottom-Up 或 Call Tree 标签页：按“Total Time”排序，排在最上面的函数往往是顶层耗时大户；注意看 Self Time（自身执行时间）是否高——高 Self Time 才是真瓶颈，不是被子函数拖累的“背锅侠”
快速聚焦可疑函数的技巧
别从头扫图。先用鼠标拖选掉帧严重的时间段（比如 FPS 曲线下跌那几帧），火焰图会自动缩放并高亮该区间内的所有活动。再点开 Call Tree，勾选“Hide system scripts”，只看你自己写的代码（比如 app.js 或 utils.ts）。如果看到某个函数反复出现、Self Time 累计占总脚本时间 20% 以上，基本就是它了。
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
验证是不是它真在作祟
找到疑似函数后，别急着改逻辑。先做两件事确认因果关系：
- 在 Sources 面板里定位该函数，加
debugger或console.time('xxx')/console.timeEnd('xxx')，手动触发几次，看实际耗时是否稳定超标 - 临时注释掉这个函数（或用 feature flag 绕过），重新录制 Performance，观察 FPS 是否回升、长条是否消失——这是最直接的证据
常见“帧杀手”模式一眼识别
有些写法在火焰图上有典型长相，见了就能猜个八九不离十：
-
Layout Thrashing（布局抖动）：火焰图里连续出现多个绿色（Recalculate Style）+ 紫色（Layout）小块交替，中间夹着 JS 黄块——大概率是循环中反复读写
offsetHeight、getBoundingClientRect()之类触发强制同步布局 - 大量短函数高频调用：火焰图底部密密麻麻一堆窄黄条，堆叠高度很高（调用栈深），Self Time 单个不高但 Total Time 很高——可能是事件监听器没防抖、requestAnimationFrame 里做了不该做的计算
- 长任务阻塞主线程：单个黄色块宽度 > 50ms，下面没太多子调用，Self Time ≈ Total Time——典型如未拆分的大数组遍历、JSON.parse 大字符串、复杂正则匹配
