for比foreach快10%–30%，因foreach有回调函数实例、上下文对象等内存分配开销，而for仅栈变量更新；超50万数据或性能敏感路径才需替换。
识别超大容量数组下 for 与 forEach 的执行效率差异，关键不在于“看代码”，而在于**可控测量 + 场景还原 + 剥离干扰**。下面分三步讲清楚怎么做。
一、构造真实超大数组并统一测试环境
避免用小数组（如1000项）测性能——差异会被噪声掩盖。建议：
- 生成 ≥ 100 万项的纯数值数组（如
Array.from({length: 1e6}, (_, i) => i)），确保内存连续、无对象引用干扰 - 在 Chrome DevTools 的 Performance 面板 中录制，或使用
performance.now()精确计时（非Date.now()） - 每次测试前调用
gc()（仅限 Chromium 启用--js-flags="--expose-gc"时）或刷新页面，排除 GC 波动影响 - 重复运行 5–10 次取中位数，跳过首轮（JIT 编译预热）
二、对比时必须控制变量，否则结果无效
常见错误是直接比 for (let i = 0; i 和 <code>arr.forEach(...)——这其实比的是“未优化 for” vs “forEach”，不是公平对比。应分别测试：
-
标准 for：每次循环都读
arr.length（暴露重复属性访问开销） -
优化 for：提前缓存
const len = arr.length，再for (let i = 0; i -
原生 forEach：不带额外逻辑，仅
arr.forEach(() => {}) -
带副作用的 forEach：如
arr.forEach(x => sum += x)，此时还要考虑闭包与作用域链成本
你会发现：优化 for 比标准 for 快 15%–25%，而即使优化后，for 仍比 forEach 快 10%–30%（Chrome 125+，100 万数值数组）。
三、观察底层行为，不止看耗时数字
打开 Chrome DevTools 的 Memory 面板 → Allocation instrumentation on timeline，录制相同操作：
-
forEach会显示明显的一次性内存分配（回调函数实例、上下文对象、隐式迭代器），尤其在首次调用时 -
for几乎无新增堆分配，只有栈上变量更新 - 若数组含对象（如
{id: i, name: 'a'+i}），forEach 的闭包捕获会引发更多指针追踪，GC pause 时间显著上升
这种内存行为差异，在长时间运行或高频循环（如动画帧、实时数据处理）中，比单纯毫秒差更致命。
真正要判断是否该换，就看这两点：数据量是否稳定超 50 万、是否在性能敏感路径（如每秒 60 次的渲染循环）。其他情况，可读性优先。
