JavaScript性能调优须基于运行时数据，遵循“测—判—改—验”闭环：用Performance面板捕获长任务与高Self Time函数定位瓶颈，Memory面板对比快照识别内存泄漏，再依瓶颈类型分片任务、批量DOM操作、避免GC与重排，并用performance.mark/measure量化验证效果。
JavaScript性能调优不能靠经验猜，必须以运行时真实数据为依据制定可验证的落地策略。核心是“测—判—改—验”闭环：先捕获主线程行为，再识别真正瓶颈，接着针对性干预，最后用相同指标验证效果。
用Performance面板锁定长任务和高开销函数
打开Chrome DevTools → Performance → 点击录制 → 完成典型用户操作（如打开列表页、滚动到底部、点击筛选）→ 停止录制。重点关注三类信号：
- 主线程上持续超过50ms的红色长任务块（用户会明显感知卡顿）
- Self Time占比高的函数（说明该函数自身耗时严重，不是子调用拖累）
- Layout、Paint、GC等渲染或内存事件密集出现的时段
右键长任务 → “Reveal in call tree” → 查看调用栈，快速定位到具体源码行。例如某次分析发现renderItem单次执行Self Time达82ms，而它被调用了120次，总耗时占帧时间70%，这就明确了优化优先级。
结合Memory面板识别渐进式性能退化
如果页面“越用越卡”，大概率存在内存泄漏。操作步骤：
- Memory → 选中“Heap snapshot” → 拍摄快照（Snapshot 1）
- 执行疑似泄漏操作（如打开关闭弹窗5次、切换路由3轮）
- 再拍一张快照（Snapshot 2） → 切换到“Comparison”视图
- 筛选“Constructor”列中新增对象数多、且Shallow Size大的类型（如闭包、EventListener、Detached DOM树）
常见泄漏点：未移除的addEventListener、全局缓存未清理、定时器未clearInterval、React/Vue组件销毁后仍持有DOM引用。
基于运行时特征选择对应优化手段
不同瓶颈类型对应不同解法，不能一概套用“节流”或“懒加载”：
- 若长任务来自同步计算（如大数据排序、模板渲染），拆分为小任务：用
setTimeout(fn, 0)或requestIdleCallback分片执行，每片控制在16ms内，保证60fps - 若高Self Time来自重复DOM操作，改为批量更新：用
DocumentFragment收集节点，或拼接innerHTML字符串一次性写入 - 若GC频繁触发（Performance中看到大量紫色“Garbage Collection”标记），检查是否在循环中创建新函数、新对象；把函数提到循环外，复用对象或使用对象池
- 若重排（Layout）密集发生，避免读写交替：先批量读取
offsetHeight等布局属性，再批量修改style，不要for循环里反复读-改-读-改
用performance.mark() + performance.measure()做轻量级埋点验证
在关键路径前后插入标记，量化优化效果：
performance.mark('start-render-list');
renderList(data);
performance.mark('end-render-list');
performance.measure('list-render-time', 'start-render-list', 'end-render-list');
console.table(performance.getEntriesByName('list-render-time'));上线后可通过performance.getEntriesByType('measure')采集真实用户数据，确认优化是否生效，而非仅依赖本地测试。
