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代码压根没执行过，方便删冗余逻辑或做按需加载

盯紧几类高频性能杀手

大部分卡顿都来自这几个典型场景，定位后基本能对症下药：

jm-jsjkxyjs02-zlm-405

使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。

下载

• 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的任务，可用于线上埋点预警

基本上就这些。工具很顺手，瓶颈类型就那么几类，关键是养成“先看数据、再改代码”的习惯。不复杂，但容易忽略。