for循环遍历数组最高效，现代引擎深度优化后比forEach、for...of快20%–50%，需缓存length并避免函数调用开销；超大数组应分片或用requestIdleCallback防阻塞。
用 for 循环遍历数组最高效
现代 JavaScript 引擎对传统 for 循环做了深度优化，尤其是当数组长度已知、不频繁修改时，它比 forEach、for...of 等更轻量、更可控。
常见误区是认为语法糖一定“更现代=更快”，但实际在大量数据（如 10 万+ 元素）下，for 循环平均快 20%–50%，且避免了函数调用开销和作用域创建。
- 始终缓存
array.length，避免每次迭代都读取属性：for (let i = 0, len = arr.length; i < len; i++) { ... } - 若需中途退出（如查找匹配项），
for可直接break或return；而forEach无法中断，必须抛错或改用some/find - 注意：不要在循环中动态修改数组长度（如
push/splice），否则易漏项或死循环
for...of 适合需要值而非索引的场景
当你只关心元素值、不依赖下标，且数组是可迭代对象（普通数组、TypedArray、Set、Map 的 values() 等），for...of 语义清晰、不易出错。
但它底层仍需创建迭代器对象，有轻微开销；且无法获取当前索引（除非手动计数），也不支持反向遍历。
立即学习“Java免费学习笔记（深入）”；
- 正确写法：
for (const item of arr) { console.log(item); } - 想同时拿到索引？别硬套：
arr.entries()更合适：for (const [index, value] of arr.entries()) { ... } - 注意：
for...of对稀疏数组（如[1,,3]）会跳过空位，但不会触发undefined回调 —— 这和forEach行为一致
慎用 forEach：它不是 for 的安全替代品
forEach 是高阶函数，设计目标是“副作用遍历”，不是“通用控制流”。它无法返回值、无法中断、无法链式继续处理，还容易引发 this 绑定问题。
很多开发者用它仅仅因为“看起来更函数式”，结果在需要提前退出或组合逻辑时被迫重构。
- 不能 break/continue：
arr.forEach(x => { if (x === target) return; /* 不会跳出循环 */ }) - this 指向默认是
undefined（严格模式），需显式传入：arr.forEach(callback, thisArg) - 性能上，每次回调都是独立函数调用，V8 虽做了内联优化，但仍有上下文切换成本
- 替代方案优先级：查找 →
find/findIndex；判断 →some/every；映射 →map；过滤 →filter
超大数组考虑分片或 requestIdleCallback
当数组超过 100 万项，无论用哪种遍历方式，单次同步执行都会阻塞主线程，导致页面卡顿。此时“高效”不只看算法复杂度，更要看响应性。
核心思路是让出控制权，把任务切片，在浏览器空闲时段执行。
- 简单分片示例：
function chunkedLoop(arr, handler, chunkSize = 1000) { let i = 0; function next() { const end = Math.min(i + chunkSize, arr.length); for (; i < end; i++) handler(arr[i], i); if (i < arr.length) requestIdleCallback(next); } next(); } - 注意：
requestIdleCallback并非所有环境都支持（如某些旧版 iOS WebView），需降级为setTimeout(..., 0) - 如果操作可并行（如纯计算），也可考虑 Web Worker，但跨线程序列化开销需权衡
真正影响性能的往往不是“选哪个遍历语法”，而是是否在循环里做了 DOM 操作、重复计算、未缓存的 getter 调用，或者忽视了数组是否真的需要全量遍历。
