JavaScript性能分析的核心是测量而非猜测，需用Chrome DevTools的Performance、Memory、Coverage面板定位Long Task、Detached DOM、未执行代码等问题，并针对性优化DOM操作、事件处理、长任务和内存泄漏。
JavaScript性能分析，就是用工具和方法看清代码在浏览器里“到底哪里慢、为什么慢、谁在拖后腿”。核心不是猜，而是测量——看主线程有没有被卡住、DOM有没有反复重排、内存有没有越用越多、事件有没有失控触发。
用Chrome DevTools快速揪出问题
这是最直接有效的手段，不用装插件，开F12就能用：
- Performance面板：点击Record，做一遍卡顿的操作（比如滚动、点按钮），停掉后看Main线程火焰图。红色长条＞50ms就是Long Task，点开就能看到是哪个函数在耗时
- Memory面板：先拍个堆快照（Heap Snapshot），再操作（比如打开又关闭弹窗），再拍一个，对比两次快照中Detached DOM节点或持续增长的对象，比如没清理的定时器、闭包里挂着的大数组
- Coverage面板（Ctrl+Shift+P搜Coverage）：能标出页面加载后哪些JS代码压根没执行过，方便删冗余逻辑或做按需加载
盯紧几类高频性能杀手
大部分卡顿都来自这几个典型场景，定位后基本能对症下药：
-
DOM操作引发的回流风暴：比如循环里反复改
element.style.width，每次都会强制同步计算布局（Forced Synchronous Layout）。解决办法是批量读、批量写，或改用transform/opacity这类只走合成层的属性 -
滚动/输入事件失控：
scroll、input每秒可能触发几十次，如果里面直接跑复杂计算，立马卡顿。必须加节流（固定间隔执行）或防抖（停了再执行） -
长任务阻塞主线程：一个函数执行200ms，整个页面就“假死”200ms。可拆成小块，用
setTimeout、requestAnimationFrame或Promise.then让出主线程，保持响应 -
内存悄悄涨不停：比如事件监听器绑在全局但没
removeEventListener，或闭包里长期持有大对象。WeakMap、及时解绑、避免意外全局变量，都是有效防线
简单但关键的测量习惯
别等用户投诉才查，日常写逻辑时就该带上“尺子”：
立即学习“Java免费学习笔记（深入）”；
- 测一段耗时：
performance.mark('start'); /*你的代码*/; performance.mark('end'); performance.measure('label','start','end');，然后查performance.getEntriesByName('label')[0].duration - 粗略测：用
console.time('xxx')+console.timeEnd('xxx')，适合开发阶段快速验证 - 监控长任务：
new PerformanceObserver监听longtask类型，自动捕获＞50ms的任务，可用于线上埋点预警
基本上就这些。工具很顺手，瓶颈类型就那么几类，关键是养成“先看数据、再改代码”的习惯。不复杂，但容易忽略。
