Chrome DevTools Performance面板可定位主线程卡顿，关键识别>50ms的Long Task；结合Memory、Coverage面板及PerformanceObserver可实现开发与线上全链路监控。
直接用 Chrome DevTools 的 Performance 面板就能看清主线程哪里被卡住，关键不是看整体快慢，而是找那些“一口气占满主线程、不让用户操作响应”的长任务。
录制一次真实交互，聚焦 Main 线程火焰图
打开目标页面 → F12 → 切到 Performance 标签 → 点击左上角圆形录制按钮 → 执行一次你怀疑卡顿的操作（比如点开弹窗、滚动列表、提交表单）→ 停止录制。DevTools 会生成完整火焰图，重点盯住 Main 区域：
- 红色或深黄色宽条（宽度 > 50ms）就是 Long Task，它正在独占主线程，用户点击、滚动、输入都会被延迟响应
- 横向越宽，阻塞时间越长；纵向嵌套越深，说明函数调用链越复杂，可能有深层循环或未优化的数据处理
- 把鼠标悬停在长条上，能直接看到耗时、调用栈顶部函数名和触发事件（如 click、scroll、timer）
点开长任务，顺藤摸瓜定位源头函数
点击任意一个 Long Task 条目，右侧 Summary 面板会显示详细调用栈。重点关注最顶层的函数：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 如果是你写的业务函数（如
handleSearch、renderList），说明逻辑本身耗时过高，需检查数据遍历、正则匹配、JSON.parse 大字符串等操作 - 如果是框架方法（如
React.render、Vue._update），要确认是否因状态频繁更新或组件过度渲染导致 - 如果顶层是第三方 SDK（如 analytics.track、ads.init），可能是其初始化或上报逻辑未做异步/节流，需查文档或隔离测试
结合 Memory 和 Coverage 辅助交叉验证
单靠 Performance 有时不够——比如主线程没明显长任务，但页面仍变慢，可能是内存持续增长拖垮 GC 频率：
立即学习“Java免费学习笔记（深入）”；
- 切到 Memory 面板 → 点 Capture Heap Snapshot 拍第一张快照 → 做几次相同操作（如打开/关闭模态框）→ 再拍一张 → 对比两次快照中 Detached DOM 节点数量是否递增，或某个构造函数实例数是否只增不减
- 按 Ctrl+Shift+P 输入 “Coverage” 打开 Coverage 面板 → 刷新页面 → 查看哪些 JS 文件大片灰色，代表加载了却完全没执行，可能是冗余模块或错误的按需加载逻辑，间接增加解析和内存压力
用 PerformanceObserver 在运行时捕获长任务
不只是开发阶段看，线上也能主动监控：
- 加一段轻量监听代码，自动捕获所有 > 50ms 的主线程阻塞
- new PerformanceObserver(list => { list.getEntries().forEach(entry => console.warn('Long task:', entry.duration, 'ms')); }).observe({entryTypes: ['longtask']});
- 配合用户行为埋点（如记录当前页面路径、触发按钮 ID），就能把“卡顿”和具体操作关联起来，不再依赖用户模糊反馈
