JS运行时性能分析是定位长任务→拆解逻辑→验证效果的闭环过程，需用Performance面板识别DOM更新、计算密集、布局抖动三类长任务，再分别用DocumentFragment、任务切片、读写分离等方案优化，并通过TBT和FID量化验证效果。
JS 运行时性能分析不是“看一眼控制台就改代码”，而是定位长任务 → 拆解执行逻辑 → 验证优化效果的闭环过程。关键不在工具多炫酷，而在能否快速锁定真实瓶颈——比如一个看似简单的列表渲染，卡顿根源可能是同步布局抖动，而非循环本身。
一、用 Performance 面板抓出真凶：识别三类典型长任务
在 Chrome DevTools 中录制用户操作（如点击筛选按钮、滚动页面），重点关注红色长条（>50ms 的主线程任务）：
-
DOM 更新密集型：时间轴中“Layout”和“Paint”频繁出现，伴随大量
appendChild、offsetHeight调用 —— 典型表现是列表刷新卡顿、滚动掉帧； - 计算密集型：时间轴中“Scripting”持续占满，无明显渲染活动 —— 常见于数据格式化、图表坐标计算、未拆分的大循环；
-
布局抖动型（Layout Thrashing）：时间轴中“Layout”反复出现小块，且紧挨着 JS 执行 —— 往往因在单次 JS 执行中交替读写 DOM 布局属性（如先读
el.offsetWidth，再设el.style.width）。
二、针对性调优：按问题类型选对解法
不要统一上 Web Worker 或节流，要匹配场景：
- 面对DOM 更新密集：用
DocumentFragment批量插入，或改用字符串拼接 +innerHTML一次性写入；清空旧列表优先用el.innerHTML = ''，而非循环removeChild； - 面对计算密集：将 >50ms 的计算任务拆成微任务（
Promise.resolve().then(...)）或setTimeout(..., 0)，让出主线程响应用户输入；复杂运算（如图像处理）移入 Web Worker； - 面对布局抖动：严格遵循“读写分离”——先批量读取所有需要的尺寸/位置（如
getBoundingClientRect()），再统一修改样式；高频读写场景可包裹进requestAnimationFrame，确保在下一帧前完成。
三、验证是否真有效：不止看 FPS，要看 TBT 和 FID
优化后不能只感觉“好像快了”。打开 Lighthouse 运行一次移动端模拟测试，重点盯两个指标：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- TBT（总阻塞时间）：应 50ms 任务超出 50ms 的部分之和，直接反映主线程被占用程度；
- FID（首次输入延迟）：应
若二者未下降，说明优化没打中靶心——可能只是把卡顿从 A 函数挪到了 B 函数，或引入了新瓶颈（如过度使用 Promise 导致微任务队列堆积）。
四、避免掉进常见误区
很多“优化”反而让情况更糟：
- 用
for...in遍历数组：它会遍历原型链，比for或for...of慢数倍，且不可预测； - 在循环里反复查 DOM：
document.getElementById('list')写在循环内，每次都要走查找流程 —— 应提至循环外缓存； - 滥用闭包保留大对象：如在事件处理器中引用整个数据列表，导致内存无法释放，长期运行后页面渐慢；
- 过早优化正则或字符串方法：现代引擎对
String.prototype.includes、RegExp优化已很充分，优先优化 DOM 和循环结构。
