JavaScript性能优化关键在识别真实瓶颈：90%卡顿源于setTimeout嵌套、未节流的resize/scroll事件或强制同步布局；应集中读写操作、用requestAnimationFrame批量更新、避免循环中频繁DOM访问，并警惕console.table和sourceMap误发生产环境。
JavaScript 性能优化不是靠堆技巧，而是优先识别和切断实际瓶颈。90% 的页面卡顿跟 setTimeout 嵌套、未节流的 resize/scroll 事件、或意外的强制同步布局（layout thrashing）直接相关。
避免强制同步布局（Layout Thrashing）
浏览器在读取某些 DOM 属性（如 offsetHeight、getBoundingClientRect()）时，若此前有未生效的样式修改，会立即触发重排（reflow），频繁读写交替就会卡死主线程。
- 把所有“读”操作集中在一起，所有“写”操作集中在一起
- 用
requestAnimationFrame批量处理动画帧内的 DOM 更新 - 避免在循环中反复访问
element.style.height或element.offsetWidth
错误示例：
throttle
- 用
lodash.throttle时注意leading/trailing默认值，不加配置可能首尾都丢事件 - 原生实现
debounce必须清上一个setTimeoutID，漏掉就导致多次调用 - Vue/React 中绑定
@scroll或onScroll时不包装，等于裸奔式监听
减少闭包与长生命周期引用
闭包本身不慢，但若内部函数被挂到全局事件或定时器里，又引用了大对象（比如整个 data 响应式数据），就会阻止垃圾回收，内存悄悄上涨。
- 事件监听器用完及时
removeEventListener，尤其动态创建的组件 - 避免在
setInterval回调里直接引用外部大数组，可提前提取必要字段 - Chrome DevTools 的
Memory > Take heap snapshot对比两次快照，看Closure下谁占得多
用 for 代替 forEach 真能提速？
单次遍历几万条数据时，for 比 forEach 快 2–5 倍，但差异主要来自函数调用开销和作用域创建——不是语法本身慢，而是 forEach 每次都要 new 一个执行上下文。
- 纯计算逻辑（无 DOM、无 await）且数组长度 > 10k，优先
for或for...of - 需要链式调用（
filter→map→reduce）时，for反而难维护，此时用Array.from+flat预过滤更有效 - V8 引擎对
for循环做了大量优化，但对for...in仍警告：它遍历的是属性名，不是数组索引，且包含原型链
真正拖慢 JS 的，往往不是语法选择，而是没意识到某个 console.table(data) 在生产环境开着，或者 sourceMap 文件被一起部署到了 CDN 上。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
