JavaScript性能优化应聚焦DOM操作、事件处理和内存泄漏三类高频问题，通过批量读写分离、使用documentFragment、节流防抖、避免隐式类型转换、及时清理引用及构建阶段优化来提升性能。
JavaScript 性能优化不是堆砌技巧，而是识别真实瓶颈后做有针对性的干预。多数场景下，盲目优化 for 循环或提前返回反而增加维护成本，真正值得投入的是 DOM 操作、事件处理和内存泄漏这三类高频问题。
减少重排重绘（Reflow & Repaint）的 DOM 操作
浏览器在修改样式、尺寸、位置等影响布局的属性时会触发重排，代价远高于单纯颜色变化。频繁操作 innerHTML、offsetHeight、getComputedStyle 都可能意外触发重排。
- 批量读写分离：先读取所有需要的布局信息（如
offsetTop、clientWidth），再统一写入样式或结构 - 用
documentFragment批量插入节点，避免多次触发插入导致的重排 - 动画优先用
transform和opacity，它们由合成线程处理，不触发布局计算 - 避免在循环中访问
offsetLeft等“强制同步布局”属性；可缓存一次结果复用
节流与防抖处理高频事件（如 scroll、input、resize）
未加控制的 scroll 事件在滚动过程中每秒可能触发数十次，直接绑定回调极易造成卡顿。节流（throttle）和防抖（debounce）是两种不同意图的控制策略。
- 节流适用于需定期响应的场景，比如滚动时更新吸顶状态：
throttle(() => { updateSticky(); }, 100)表示至少间隔 100ms 执行一次 - 防抖适用于“等待用户操作结束”，比如搜索框输入：
debounce(() => { fetchSuggestions(input.value); }, 300)表示输入停顿 300ms 后才发起请求 - 注意：不要在
addEventListener中直接传入未包装的函数，否则每次渲染都新建闭包，还可能无法正确移除监听器 - 现代方案可考虑
requestIdleCallback做低优先级任务调度，但需注意兼容性
避免隐式类型转换与原型链过长的性能陷阱
V8 引擎对常见模式有强优化，但一旦触发“去优化（deoptimization）”，性能会断崖式下降。典型诱因包括：在函数内动态添加属性、混用数据类型、访问不存在的原型属性。
立即学习“Java免费学习笔记（深入）”；
- 对象初始化时尽量一次性定义全部属性，避免后续
obj.newField = value导致隐藏类变更 - 数组尽量保持单一类型（如全是数字），避免
[1, '2', true]这种混合类型数组，V8 会退化为慢路径 - 慎用
with和eval，它们会关闭 JS 引擎的大部分优化能力 - 遍历对象属性优先用
Object.keys(obj).forEach而非for...in，后者会遍历整个原型链，且顺序不可控
及时清理定时器、事件监听器与闭包引用
内存泄漏在 SPA 中尤为隐蔽，常见于组件卸载后仍保留对 DOM 节点或全局对象的引用，导致垃圾回收器无法释放。
- 使用
setTimeout或setInterval时，务必在不需要时调用clearTimeout/clearInterval；建议将 timer ID 存为变量并统一管理 - 通过
addEventListener添加的监听器，应在对应生命周期钩子（如 React 的useEffectcleanup、Vue 的beforeUnmount）中用removeEventListener移除，注意函数必须是同一引用 - 避免在闭包中长期持有大型数据（如未裁剪的图片
Blob、大数组），尤其在异步回调中；可显式置为null辅助 GC - Chrome DevTools 的
Memory面板配合堆快照对比，比凭感觉更可靠
最常被忽略的一点：很多“优化”其实发生在构建阶段——Tree-shaking 是否生效？console.log 是否残留？Source Map 在生产环境是否关闭？这些配置层面的问题，往往比改几行 for 循环影响更大。
