直接查看Performance面板主线程火焰图和帧耗时分布，重点识别50ms以上长任务、频繁Layout/Paint块及FPS骤降帧；录制需模拟真实交互，禁用插件与service worker；分析时聚焦调用栈中自有函数、JS与渲染耗时分离打点、结合资源加载与布局偏移交叉定位，并用PerformanceObserver实时捕获隐性性能问题。
直接看 Performance 面板里的主线程火焰图和帧耗时分布，重点抓三类信号：50ms 以上的长任务、频繁出现的 Layout/Paint 块、以及 FPS 曲线中突然下坠的帧。这些不是孤立现象，而是相互关联的线索。
录制前做好环境准备
打开 Chrome DevTools → Performance 标签 → 勾选 “Screenshots” 和 “Memory” → 点击录制按钮（●）→ 执行一次典型用户操作（比如点击按钮触发列表渲染、滚动首屏、切换 Tab）→ 停止录制。不要用空闲状态录，要模拟真实交互节奏。
推荐在无痕窗口 + 禁用所有插件下操作，避免干扰；若项目有大量异步逻辑，可临时关闭 service worker 或缓存策略，确保复现路径干净。
聚焦主线程中的长任务与调用栈
录制完成后，先看顶部 FPS 轨道：绿色条是健康帧（≤16.67ms），黄色/红色说明掉帧。往下拉到 Main Thread 区域，红色高亮的长任务（duration ≥ 50ms）就是首要怀疑对象。
- 点击某个长任务，展开调用栈，找是否包含你自己的函数名（如 formatData、generateTree、calculateOffset），而不是只盯着 React/Vue 内部方法
- 观察任务是否集中在 render/commit/update 阶段之后——这说明计算被拖进了渲染流程，本该提前或缓存
- 留意是否有重复出现的相同函数（比如每次滚动都调一次 getVisibleItems），大概率缺少 useMemo 或 computed 缓存
拆解单帧生命周期，区分 JS 逻辑与渲染开销
仅靠自动录制不够细，需主动打点。在关键代码段前后加 performance.mark：
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- update-start / update-end：包裹状态计算、数据转换、排序过滤等纯 JS 操作
- render-start / render-end：仅包裹实际 DOM 更新、Canvas 绘制、CSS 变更等渲染动作
- 再用 performance.measure 分别记录 update-duration 和 render-duration
如果 update-duration 波动大但 render-duration 稳定，问题在数据处理逻辑；如果两者同步飙升，可能是内存分配激增或 GC 触发，得切到 Memory 面板验证。
结合资源加载与布局偏移交叉定位
有些“卡顿”其实不是 JS 慢，而是上游拖累。在 Performance 面板底部的 Summary 或 Bottom-Up 标签里，筛选类型为 resource、layout-shift、longtask 的条目：
- 某帧前后紧跟着一个大图加载完成（resource 类型，transferSize > 1MB），同时出现紫色 Layout 块 → 图片插入导致强制重排
- 某次点击后立即触发 longtask，紧接着一帧内出现多个 layout-shift 条目 → JS 修改了未设置宽高的图片容器，又没做防抖
- LCP 元素（最大内容）的 resource 条目 duration 很高，而它又是由 JS 动态插入的 → 渲染逻辑和资源加载耦合过紧
这时要回到 Network 面板，看对应资源是否启用压缩、是否预加载、是否设置了尺寸属性。
用 PerformanceObserver 实时捕获隐性压力
开发阶段可注入轻量监控，不依赖手动录制：
- 监听 longtask 类型，拿到 entry.attribution.scriptURL 定位具体脚本位置
- 监听 measure 类型，聚合 frame-duration 数据，当 p95 > 25ms 时打印警告
- 监听 layout-shift，发现 CLS 突增时，记录当前 DOM 快照（document.documentElement.outerHTML.slice(0, 500)）辅助回溯
这类监控能暴露那些“偶尔卡一下、但录制时抓不到”的问题，尤其适合高频交互场景。
