for循环在大多数场景下比forEach快2–5倍，尤其数组长度超1000时更明显；因forEach每次迭代创建新函数作用域、隐式调用回调且无法用break中断，而for是原生指令级控制。
for 循环比 forEach 快多少？
直接说结论：for 循环在大多数场景下比 forEach 快 2–5 倍，尤其在数组长度超过 1000 时差异明显。这不是玄学，而是因为 forEach 每次迭代都创建新函数作用域、隐式调用回调、无法提前中断（break 无效），而 for 是原生指令级控制。
-
forEach无法用return跳出整个循环，只能跳出当前回调——这点常被误认为“能中断” - 如果只是读取或简单计算（如求和），
for和for...of性能接近，但for...of在 V8 中有额外对象遍历开销 - 使用
for (let i = 0; i 时，现代 JS 引擎基本会优化掉重复读取 <code>arr.length，无需手动缓存（除非你在循环中动态修改数组长度）
map/filter/reduce 真的慢吗？什么时候该用？
它们不“慢”，但有明确的适用边界：语义清晰 + 不可变意图明确时才用。性能上，它们比手写 for 多一次数组分配（map）、多一次遍历（filter 后接 map）或隐式累积开销（reduce）。V8 对内置方法做了大量内联优化，但无法绕过其设计契约。
-
map一定会返回新数组，哪怕你只想要第一个转换结果——此时用for+break更直接 -
filter().map()是典型双遍历，等价于一次for中条件判断 + 推入，后者快且内存友好 -
reduce在累加简单值（如数字求和）时，不如for直观；但处理嵌套结构聚合（如扁平化树、分组统计）时，可读性优势压倒微小性能损失
TypedArray 和 for-of 的性能陷阱
如果你操作的是纯数字集合，Uint32Array 或 Float64Array 配合 for 循环，比普通 number[] 快 3–10 倍。但注意：for...of 遍历 TypedArray 会触发包装器创建，反而比传统 for 慢 20%+。
- 不要对
TypedArray用forEach——它会降级为通用迭代器路径，失去底层优化 -
for...in绝对不用在数组上：它枚举属性名（字符串），顺序无保证，还可能遍历原型链上的可枚举属性 - V8 中
for (const x of arr)对普通数组已优化得不错，但若需索引（如同时访问arr[i]和arr[i+1]），仍推荐for (let i = 0; i
真实场景下的选择建议
别一上来就 micro-benchmark。先看代码是否跑在热路径（如动画帧、高频事件、大数据量初始化），再决定是否替换。多数业务逻辑里，可读性 > 0.1ms 差异；但 WebGL 数据预处理、实时音频采样分析这类场景，一个 for 能省下几毫秒就是关键。
立即学习“Java免费学习笔记（深入）”；
- 需要中断（
break/continue）或复用索引 → 无条件选for - 做数据转换且后续还要链式操作（如
data.map(...).filter(...).sort(...)）→ 用函数式，V8 会尝试优化，且逻辑不易出错 - 数组长度稳定且大于 10k，纯数值运算 → 换
TypedArray+for，并确保没有闭包捕获大对象 - 用
lodash或ramda？它们的map/filter在小数组上开销更大，除非你依赖其空值安全或柯里化特性
const arr = new Float64Array(100000);
let sum = 0;
for (let i = 0; i < arr.length; i++) {
sum += arr[i] * 2;
}
// ✅ 正确：TypedArray + for，无装箱，无迭代器开销
// ❌ 错误：for...of arr 或 arr.forEach(x => sum += x * 2)真正影响性能的往往不是“用哪个遍历”，而是“要不要遍历”——比如把多次 arr.find + arr.map 合并成一次 for，或者用 Map 替代 findIndex 查找。这些细节比选语法更关键。
