JavaScript性能优化核心是提升关键路径的快、稳、可预测性，聚焦FCP+TTI、Long Tasks占比、内存泄漏及响应卡顿，而非炫技或次要指标。
JavaScript 性能优化不是“写得更炫”而是“让关键路径更快、更稳、更可预测”。核心判断标准是：首屏可交互时间（FCP + TTI）、长任务（Long Tasks）占比、内存泄漏风险，以及用户操作响应是否卡顿。其他指标如 bundle 大小或 Lighthouse 分数只是间接参考。
如何识别真实瓶颈：别只看 console.time
Chrome DevTools 的 Performance 面板录制后，重点看主线程火焰图里持续 > 50ms 的任务块（即 Long Task），尤其注意 Script Evaluation 和 Layout 阶段的堆叠。常见误判是把网络请求耗时当成 JS 执行慢——实际可能是 fetch() 后没做流式处理，或在 then() 里一次性解析了 10MB JSON。
- 用
performance.measure()替代手写console.time()，它能被 DevTools 自动采集并关联到时间线 - 避免在
scroll或input回调中直接调用getBoundingClientRect()或offsetHeight—— 这会强制同步重排（Layout Thrashing） - 对高频事件使用
requestIdleCallback()延迟非关键逻辑，但注意其兼容性（IE 不支持，需 fallback 到setTimeout(..., 1)）
减少执行开销：函数和循环里的隐藏成本
现代 JS 引擎对简单循环和内联函数优化很好，但以下模式仍易触发 deopt（去优化）：在 for 循环中动态修改数组长度、在闭包里引用超大对象、频繁使用 eval() 或 with。V8 的 TurboFan 编译器对类型稳定的代码最友好。
- 数组遍历优先用
for（而非forEach），尤其当需要提前break或复用索引时 - 避免在热路径中调用
JSON.parse()多次解析同一字符串；可缓存结果，或用structuredClone()（若只需深拷贝） - 函数参数尽量保持类型一致，例如始终传
number而非有时string有时number，否则 V8 可能降级为解释执行
内存与 GC：看不见的卡顿源头
内存问题不总表现为“内存占用高”，而常体现为“偶发性卡顿”——这是垃圾回收（GC）暂停主线程导致的。重点关注闭包持有 DOM 节点、未清理的事件监听器、定时器回调中引用外部大对象这三类泄漏模式。
立即学习“Java免费学习笔记（深入）”；
- 用 Chrome 的
Memory面板录制“Allocation instrumentation on timeline”，过滤出长期存活的Detached DOM tree - 移除元素前，手动清除其绑定的事件：
el.removeEventListener('click', handler)；若用事件委托，确保代理节点生命周期可控 - 避免在
setInterval()回调中不断创建新对象（如{ x: i, y: Date.now() }），改用对象池或复用已有实例
真正难优化的从来不是单个函数，而是跨模块的状态同步、异步链路中的错误兜底、以及第三方 SDK 的不可控副作用。上线前务必在低端 Android 设备上实测滚动帧率和输入延迟，而不是只依赖本地 MacBook 的 Performance 面板。
