应缓存数组长度避免重复计算：for (let i = 0, len = arr.Length; i
避免在循环里重复计算数组长度
写
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';
console.log(el.offsetLeft); // 触发重排
el.style.top = '20px'; // 再次重排换成：
console.log(el.offsetLeft);
el.style.cssText = 'left: 10px; top: 20px;';真正拖慢 JS 性能的，往往不是算法复杂度，而是那些看起来无害的 DOM 交互、调试残留和作用域模糊带来的隐式开销。这些点不报错，也难被 profiler 高亮，但叠加起来会让 60fps 变成 30fps。
