性能敏感场景下应优先选用 for 循环而非 forEach 或 for...of，因其无函数调用开销、支持中断且更快；大数据量时需预分配数组、避免链式操作，并按查找目的选择 some/includes/find 等轻量方法。
性能敏感场景下，数组方法的选择不能只看写法是否简洁，关键要看执行开销、内存占用和是否满足中断或复用需求。小数组差异不明显，但一旦数据量超过万级，不同方法的耗时、栈深度、GC压力就可能拉开数量级差距。
大数据遍历：优先用 for，慎用 forEach 和 for...of
for 循环仍是性能天花板——无函数调用、无迭代器对象创建、索引访问最直接。尤其在百万级数字累加或批量计算中，它比 forEach 快 30%–50%，且支持 break/continue。
- 务必缓存 arr.length，避免每次循环都读取属性：
for (let i = 0, len = arr.length; i < len; i++) - forEach 在 V8 中无法被 JIT 充分内联，回调函数带来额外开销；不支持中断，误用可能导致全量遍历
- for...of 语法友好，适合需解构或配合 async/await 的场景，但底层走迭代协议，性能略逊于 for
生成新数组：map vs 手动 for + 预分配
map 语义清晰、可读性高，现代引擎已对其做了预分配优化，日常开发足够高效。但在极端性能要求下（如实时渲染管线中的顶点变换），手动方案更可控。
- 若已知结果长度，用 new Array(len) 预分配，再通过下标赋值，比 push() 快且避免多次内存扩容
- map 返回新数组，不可变语义安全；手动方案修改原数组或自行管理目标数组，需权衡副作用
- 链式操作（如 map().filter().reduce()）易引发多次遍历，超大数组建议合并逻辑或用惰性求值库
查找与过滤：按目的选方法，避免“杀鸡用牛刀”
不是所有查找都要 filter 或 findIndex。高频、短路、单次判定类操作，有更轻量的替代方案。
立即学习“Java免费学习笔记（深入）”；
- 判断存在性：用 some() 或 every()，一命中即退出，比
filter().length > 0少遍历至少一半 - 简单值匹配：includes()（支持 NaN）或 indexOf()（严格相等），比 findIndex 回调快 2–3 倍
- 复杂条件且只需首个结果：用 find()，而非 filter()[0] —— 后者强制构建完整新数组再取首项
- 超大数组反复查找：考虑提前转为 Set 或对象哈希表，O(1) 查找替代 O(n)
合并数组：根据规模与副作用决定策略
拼接不是语法问题，而是内存与栈安全问题。数组越大，越要警惕隐式展开带来的风险。
- 小数组（< 1000 项）：扩展运算符
arr1.push(...arr2)最简明，但注意 V8 参数上限约 65536 - 中大数组（1000–10w）：用 concat()，不改原数组、不爆栈、内存开销可控，生产环境首选
- 超大数组或内存受限：用 for...of + push，原地追加、零额外内存、绝对安全，只是代码稍长
- 禁止在高频循环中反复 concat 或展开，会快速触发 GC 压力甚至卡顿
