缓存数组长度能优化性能，因为arr.length是访问器属性，反复读取可能触发getter调用或属性查找开销；缓存为局部变量后，减少属性访问次数，便于引擎做边界确定性优化，且时间复杂度稳定为O(1)。

在 JavaScript 中，通过缓存数组长度可以避免每次循环都读取 arr.length，从而小幅提升 for 循环性能，尤其在大数组或高频执行场景下更明显。

为什么缓存长度能优化性能？

arr.length 是一个访问器属性（getter），虽然现代引擎做了很多优化，但在某些情况下（比如数组被代理、重写了 length、或处于严格模式下的某些边界情况），反复读取仍可能带来额外开销。更重要的是，缓存后可减少属性查找次数，也便于 JS 引擎做确定性优化（如提前判断循环边界）。

怎么正确缓存数组长度？

把 arr.length 提前赋值给一个局部变量，用该变量作为循环终止条件：

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

✅ 推荐写法（缓存）：

立即学习“Java免费学习笔记（深入）”；

const arr = [/* 一万个元素 */];
for (let i = 0, len = arr.length; i < len; i++) {
  console.log(arr[i]);
}

❌ 不推荐写法（不缓存）：

for (let i = 0; i < arr.length; i++) { // 每次迭代都访问 arr.length
  console.log(arr[i]);
}

哪些情况缓存特别有用？

• 数组非常大（例如 >10⁵ 元素），且循环体轻量（如只做赋值或简单计算）
• 循环在热代码路径中频繁执行（如动画帧、游戏逻辑、数据批量处理）
• 数组是 Proxy 对象或自定义了 length getter（此时每次访问都触发函数调用）
• 目标环境是较老的 JS 引擎（如 IE 或早期 Node.js），优化能力有限

注意事项和常见误区

• 缓存只适用于 长度不会在循环中改变 的场景；如果循环内会 push/pop/splice，则不能缓存，否则可能跳过或重复遍历元素
• 使用 let 声明 i 和 len 在块级作用域内更安全，但性能影响几乎可忽略
• 现代 V8（Chrome / Node.js）等引擎对 i 有良好优化，实际差异往往在纳秒级；是否缓存应以可读性和语义清晰为先
• 比起长度缓存，更值得优化的是避免在循环中做重复计算、DOM 操作或函数调用