应缓存数组长度避免重复计算：for (let i = 0, len = arr.length; i < len; i++)，防止每次迭代重新读取arr.length造成性能开销。
避免在循环里重复计算数组长度
写 for 循环时直接用 arr.length 做条件判断，每次迭代都会重新读取属性，对长数组或频繁执行的循环有明显开销。
更稳妥的做法是把长度缓存为局部变量：
for (let i = 0, len = arr.length; i < len; i++) { ... }
现代 JS 引擎（V8 等）已能做部分优化，但不保证所有场景都生效，尤其当 arr 是类数组对象或带 getter 的代理对象时，length 可能被重新求值。
用 const 和 let 替代 var 提升作用域效率
var 的函数作用域和变量提升会导致引擎难以静态分析变量生命周期，影响优化编译。而 const 和 let 的块级作用域、暂时性死区（TDZ）让 V8 更容易识别不可变绑定和内存分配时机。
立即学习“Java免费学习笔记（深入）”；
- 基础类型用
const：如const PI = Math.PI，明确告诉引擎该值不会重赋值 - 对象/数组若只改内部属性，仍可用
const；只有需重新赋值才用let - 避免在循环中用
var声明计数器——它会泄漏到函数顶层，干扰闭包和 GC
慎用 console.log 和开发者工具开启状态
很多人忽略：console.log 不只是“输出”，它会强制触发堆快照、格式化对象（包括遍历原型链）、甚至阻塞某些渲染帧。生产环境未移除时，可能让页面卡顿数倍。
实际建议：
- 上线前用构建工具（如 Webpack 的
DefinePlugin）全局替换掉console.*调用 - 开发中用条件包裹：
if (process.env.DEBUG) console.log(...) - Chrome DevTools 开着“Performance”或“Memory”面板录制时，JS 执行本身就会降速 2–5 倍，别把它当成真实性能基准
减少重排（reflow）与重绘（repaint）的触发频率
DOM 操作是前端性能黑洞之一。每次读取 offsetTop、clientWidth、getComputedStyle 等布局相关属性，浏览器都可能被迫同步计算样式和布局，打断渲染流水线。
关键原则是「读-写分离」：
- 把所有读操作集中在一起（触发一次重排），再集中写（批量修改 class 或 style）
- 用
documentFragment批量插入节点，避免多次触发父容器重排 - 动画优先用
transform和opacity，它们走合成层，不触发布局计算
比如不要这样写：
el.style.left = '10px';<br>console.log(el.offsetLeft); // 触发重排<br>el.style.top = '20px'; // 再次重排
换成：
console.log(el.offsetLeft);<br>el.style.cssText = 'left: 10px; top: 20px;';真正拖慢 JS 性能的，往往不是算法复杂度，而是那些看起来无害的 DOM 交互、调试残留和作用域模糊带来的隐式开销。这些点不报错，也难被 profiler 高亮，但叠加起来会让 60fps 变成 30fps。
