JavaScript性能优化的核心是减少主线程阻塞、降低内存开销、避免重复计算和无效渲染；需缓存DOM引用、用DocumentFragment批量操作、及时清理闭包引用、将耗时计算移至Web Worker。
JavaScript性能优化的核心是减少主线程阻塞、降低内存开销、避免重复计算和无效渲染。很多慢，不是因为代码“复杂”，而是某些看似无害的习惯在高频或大数据量下被急剧放大。
避免在循环中频繁访问 DOM
每次读写 document.getElementById、innerHTML 或 offsetTop 等属性，都可能触发浏览器强制重排（reflow）或重绘（repaint），尤其在 for 循环里反复调用，性能损耗极明显。
- ✅ 正确做法：把 DOM 引用缓存到变量中，批量读写；更新多个节点时，先用 DocumentFragment 构建，再一次性插入
- ❌ 反例：for (let i = 0; i ${i}`; } —— 每次都触发重排+解析 HTML
慎用 console.log 和 debugger
开发时习惯性打日志没问题，但上线前未清理的 console.log 在大量调用（如动画帧、滚动事件）中会显著拖慢执行速度，部分浏览器甚至会同步序列化对象。而 debugger 语句一旦残留，会强制中断执行，等同于卡死。
- ✅ 建议：用构建工具（如 Webpack 的 DefinePlugin）在生产环境自动移除 console；或封装一个安全的 log 函数，通过环境变量开关
- ❌ 反例：requestAnimationFrame(() => { console.log(data); render(); }) —— 每秒 60 次日志，数据大时直接掉帧
减少闭包滥用与长生命周期引用
闭包本身不慢，但若内部函数长期持有对外部大对象（如整个 DOM 树、大型数组）的引用，会导致这些对象无法被垃圾回收，内存持续增长，最终引发 GC 频繁停顿。
立即学习“Java免费学习笔记（深入）”；
- ✅ 正确做法：及时解除事件监听器（removeEventListener）、清空定时器（clearTimeout）、手动置空不再需要的大引用（obj = null）
- ❌ 反例：function init() { const bigData = new Array(1e6).fill(0); document.addEventListener('click', () => console.log(bigData.length)); } —— bigData 被闭包捕获，永远不释放
避免同步阻塞操作：正则、JSON.parse、大型计算
一段耗时 50ms 的同步代码，在主线程上就等于让用户界面卡顿一帧（16ms 一帧）。像复杂正则匹配、解析几 MB 的 JSON、或未分片的数组遍历，都极易超标。
- ✅ 替代方案：用 Web Worker 处理纯计算任务；JSON 解析前先校验长度或流式解析；正则加 ^、$ 锚点避免回溯爆炸
- ❌ 反例：JSON.parse(largeString) 直接在主线程解析 2MB 响应体；或用 /(a+)+b/.test(str) 匹配恶意输入
不复杂但容易忽略——性能问题往往藏在“写起来最顺手”的那几行里。养成提前想“它会在哪被调用？频率多高？数据多大？”的习惯，比事后优化更有效。
