真实性能差异需用Benchmark.js在真实环境实测，小数组无差别，大数据量（如10万）时for缓存length最快（≈0.8ms），forEach（≈2.3ms）等较慢，差异源于引擎优化程度、函数调用、迭代器开销等；应结合业务场景权衡速度与可维护性。
直接测，别猜。
性能差异不是靠文档背出来的，得在真实环境里跑数据。不同方法在小数组上几乎没差别，但一旦数据量上到几万、几十万，差距就明显了。关键不是“谁最快”，而是“快在哪、为什么快、代价是什么”。
用 Benchmark.js 做准确定量对比
手动写 `console.time()` 容易受干扰，推荐用专业工具。比如：const Benchmark = require('benchmark');
const suite = new Benchmark.Suite();
const arr = Array.from({ length: 100000 }, (_, i) => i);
suite
.add('for loop', () => {
for (let i = 0; i < arr.length; i++) {
arr[i] *= 2;
}
})
.add('for with cached length', () => {
for (let i = 0, len = arr.length; i < len; i++) {
arr[i] *= 2;
}
})
.add('forEach', () => {
arr.forEach((v, i) => {
arr[i] = v * 2;
});
})
.add('for...of', () => {
let i = 0;
for (const v of arr) {
arr[i++] = v * 2;
}
})
.on('cycle', event => console.log(String(event.target)))
.run();常见结果（V8 12.x+ 环境，10 万整数数组）：
-
for（缓存 length）：≈ 0.8ms -
for（不缓存 length）：≈ 1.1ms -
for...of：≈ 1.6ms -
forEach：≈ 2.3ms -
map（生成新数组）：≈ 3.7ms -
for...in：≈ 18ms（且结果不可靠）
注意：map 慢不是因为遍历本身，而是它要分配内存、创建新数组、拷贝引用——这是功能带来的开销，不是“效率低”。
看引擎底层，理解为什么有差距
- `for` 循环是 JS 引擎最熟的结构，直接编译为高效字节码，无函数调用栈、无闭包捕获、无迭代器协议开销。 - `forEach` 每次迭代都要调用一次回调函数，V8 虽然做了内联优化，但仍有上下文切换成本；稀疏数组还会额外跳过空位。 - `for...of` 依赖迭代器协议，每次取值要走 `next()` 方法，涉及对象属性访问和状态维护。 - `for...in` 最慢，因为它要枚举所有可枚举属性（包括原型链），还要做字符串键转换、类型判断、顺序不确定。别只看数字，结合业务场景判断“真慢”还是“假慢”
- 如果你只是遍历并修改 DOM 类名，`forEach` 慢 1ms 和 `for` 慢 0.8ms 对用户毫无感知，可读性更重要。 - 如果你在处理实时日志流（每秒数万条），或做 canvas 像素级计算，那 `for` 缓存 length 就值得坚持。 - 如果你在做数据转换（如后端返回原始数据，前端要转成 UI 模型），`map` 多花的 1–2ms 换来不可变、可链式、易测试的代码，非常划算。 - `filter` + `find` 组合查一个元素？不如直接 `find` —— `filter` 会遍历全部再取 `[0]`，白干 99% 的工作。几个容易被忽略但影响实测的关键点
- 测试前清空 CPU 缓存（重启浏览器或用隐身模式），避免 JIT 优化干扰。 - 不要在循环体里做 `console.log`、`document.getElementById` 这类高开销操作，它们会淹没遍历本身的耗时。 - 避免在 `forEach` 回调里修改原数组长度（如 `push`/`splice`），这会导致跳过元素或死循环。 - `for...in` 绝对不要用于数组——它遍历的是“键名字符串”，不是数值索引，`arr[0]` 和 `arr["0"]` 虽等价，但语义错、性能差、顺序乱。不复杂但容易忽略。
