JavaScript性能优化核心是减少计算、避免主线程阻塞、合理管理内存与资源；需避免频繁DOM操作、隐式类型转换、闭包内存泄漏及加载时机不当等问题。
JavaScript性能优化核心是减少不必要的计算、避免阻塞主线程、合理管理内存和资源。常见陷阱往往藏在看似无害的写法里，而不是大段复杂逻辑中。
避免频繁的DOM操作
每次直接读写DOM都会触发重排（reflow）或重绘（repaint），开销很大。比如循环中反复修改元素样式或innerHTML，会强制浏览器多次渲染。
- 用documentFragment批量插入节点
- 把多次读取（如offsetTop、getBoundingClientRect()）合并为一次，缓存结果
- 用CSS class切换代替逐个设置style属性
- 对动画场景，优先使用transform和opacity，它们能走合成层，不触发布局计算
警惕隐式类型转换和装箱操作
像arr.forEach(item => item.toString())这类写法，在循环中对原始值（如number）反复调用toString()，会触发临时包装对象创建（装箱），增加GC压力。
- 字符串拼接优先用模板字面量或Array.join()，少用+=
- 比较时用===而非==，避免运行时类型推断
- 遍历数组用for或for...of，比forEach或map更轻量（尤其不需要返回新数组时）
函数与闭包中的内存隐患
闭包容易导致本该被回收的对象长期驻留内存，特别是事件监听器、定时器、或引用了大对象的回调中。
立即学习“Java免费学习笔记（深入）”；
- 及时清除不再需要的addEventListener，或用{once: true}
- 避免在定时器回调中持续引用外部大对象（如整个dataList），只传必要字段
- 不用var声明循环变量（易造成闭包捕获同一引用），用let或函数参数隔离作用域
- 大型数据处理后，手动将局部引用设为null（如bigData = null），辅助GC
加载与执行时机不合理
脚本位置、执行方式、是否真正需要，直接影响首屏和交互响应。
- 非关键JS用defer或async，避免阻塞HTML解析
- 用IntersectionObserver代替scroll事件监听做懒加载，避免高频触发
- 计算密集任务拆成微任务（queueMicrotask）或用Web Worker移出主线程
- 避免在load或DOMContentLoaded里塞大量初始化逻辑，按需延迟执行
基本上就这些。不复杂但容易忽略——多数性能问题不是来自算法复杂度，而是日常写法里的小习惯。
