for循环在多数场景下仍是最快选择，因现代引擎深度优化；forEach适合副作用操作但无法中断；map/filter等声明式方法应按需使用，注意性能开销；for...of兼顾可读性与控制力；真正瓶颈常在循环体内操作。
for 循环仍是多数场景下最快的选择
现代 JavaScript 引擎对 for 循环做了深度优化，尤其在遍历纯数组时，性能通常优于 forEach、map 等高阶函数。这不是过时的“手写循环”执念，而是实测结果：V8（Chrome / Node.js）中，for (
let i = 0; i 的执行开销最小，且支持提前退出（break）、跳过（continue）和索引复用。
- 避免在每次迭代中重复读取
arr.length—— 提前缓存更稳：for (let i = 0, len = arr.length; i - 若需修改原数组（如删除匹配项），倒序遍历可防止索引错位：
for (let i = arr.length - 1; i >= 0; i--) - 不要用
for...in遍历数组 —— 它枚举所有可枚举属性（包括原型链上的），顺序不保证，且可能意外访问到非数字键
forEach 适合副作用操作，但无法中断或返回新数组
forEach 语义清晰：只做遍历 + 执行回调，不关心返回值。但它内部强制同步执行、无法 break 或 return 中断循环，也不生成新数组 —— 这些不是 bug，是设计使然。
- 适合日志打印、DOM 批量更新、发送多个请求（注意并发控制）等纯副作用场景
- 想中途退出？改用
for循环，或用some/every（它们在回调返回真/假时自动终止） - 误以为
return能跳出forEach？它只会退出当前回调，下一轮仍继续
map/filter/find 等方法该用就用，但别为语法糖牺牲可读性或性能
map、filter、find 是声明式操作的基石，代码意图一目了然。但它们都创建新数组（find 除外），且底层仍需遍历全部元素（除非短路）。
-
filter后立刻要map？考虑用flatMap合并一次遍历，减少中间数组开销 -
大数据量（>10k 元素）且只需找一个匹配项？
find比filter(...)[0]快得多 —— 后者强制遍历完整个数组 - 嵌套循环中频繁调用
includes或indexOf？预处理成Set或对象哈希表，把 O(n) 查找降为 O(1)
const ids = [1, 2, 3, 4, 5];
const lookup = new Set(ids); // 替代 arr.includes(x)
const target = 3;
if (lookup.has(target)) {
// ✅ O(1) 查找
}for...of 是兼顾可读性与可控性的现代替代方案
for...of 遍历的是可迭代对象（包括数组、字符串、Map、Set），语法比传统 for 更简洁，支持 break、continue 和 await，且不暴露索引细节 —— 适合“只关心值”的场景。
立即学习“Java免费学习笔记（深入）”；
- 需要索引？用
entries()：for (const [i, val] of arr.entries()) - 遍历稀疏数组（含空槽）？
for...of会跳过空位，而for循环仍会触发undefined回调 - 注意：不能直接用于普通对象 —— 它们默认不可迭代，需先用
Object.keys()等转成数组
真正影响效率的往往不是遍历语法本身，而是循环体内的操作：频繁 DOM 访问、未缓存的函数调用、意外的装箱/拆箱、或在循环中反复构造正则对象。先确认瓶颈在哪，再选工具。
