缓存长度的正向 for 循环是大数组遍历最优解，可节省5–10%时间；需避免每次读取 arr.length 导致的属性查找与原型链访问开销。
大数组遍历性能优化不是堆砌技巧，而是围绕 JavaScript 引擎执行机制做减法：减少属性访问、绕过抽象层、避免隐式开销。核心目标是让 V8 等引擎能高效编译、内联、预取，而不是被语法糖或动态行为拖慢。
用缓存长度的正向 for 循环作为默认选择
这是目前最稳定、最快、兼容性最好的方案，尤其适合 10 万以上元素的场景。
- 每次读 arr.length 都触发属性查找和可能的原型链访问，缓存后可节省 5–10% 时间（百万级数组效果明显）
- 写法：for (let i = 0, len = arr.length; i
- 正向比反向更利于 CPU 缓存预取；索引计算简单，JIT 优化充分
- 支持 break、continue、索引直接操作，便于边遍历边控制逻辑
避开高开销的遍历语法
forEach、for...of、for...in 表面简洁，但底层代价不低，大数据量下差异显著。
- forEach：强制创建闭包 + 每次迭代函数调用 + 无法中断，比 for 慢 20–30%
- for...of：需构造迭代器对象 + 调用 next() + 隐式类型检查，比 for 慢 15–25%，仅推荐用于小数组（
- for...in：设计用于对象，遍历数组时 key 是字符串、会遍历原型链、不保证顺序，完全不适用
根据数据特征选更底层的数据结构
当数组只存数字且类型固定，普通 Array 就成了性能瓶颈。
- 改用 TypedArray（如 Int32Array、Float64Array）：内存连续、无类型推断、无隐藏类切换，遍历快 2–4 倍
- 初始化时用 new Int32Array(n) 预分配空间，比反复 push 快得多
- 若为只读批量处理，配合 "use strict" 和明确变量声明，有助于 V8 启用更多优化路径
规避遍历中修改数组结构
在 for 循环里调用 push、splice、pop 会引发内部存储重分配和隐藏类重建，大幅拉低速度。
- 筛选/映射需求优先用 filter 或 map（它们虽比 for 慢，但语义安全、副作用可控）
- 必须边遍历边删：改用 while + 手动下标管理，或先收集待操作索引，再统一处理
- 高频增删场景考虑换用 Set 或 Map，而非密集操作数组
