别再只用 forEach 了！JS for...of 遍历的真实坑与高光时刻

日常写业务逻辑，数据遍历简直是必修课。很多时候，咱们拿到一个数组下意识就敲 forEach，觉得方便又直观。可一旦需求变复杂，比如遍历到某个条件必须中断，或者要获取当前的索引做计算，forEach 立马显得力不从心，要么抛出异常，要么被迫用标志位去硬扛。这时候，for...of 才是真正的救场王。

for...of 的核心优势不在于语法有多新，而在于它直接基于迭代器协议（Iterator Protocol）工作。这意味着它能处理的对象范围远不止数组。无论是 Set、Map 这些 ES6 新物种，还是普通的字符串，甚至是 DOM NodeList，只要实现了 iterable 接口，就能被它稳稳拿捏。很多人容易把它和 for...in 搞混，其实区别很明显：for...in 遍历的是对象的所有枚举属性键名，而 for...of 拿到的则是具体的值。在处理纯粹的数据集合时，后者显然更符合直觉，不用再去手动查表映射。

实际项目中，最让人上头的点往往在流程控制上。forEach 内部没有 break 和 return，想在中间跳出循环通常得折腾一层闭包。而 for...of 回归了最朴素的 break 机制，遇到异常情况立刻停止后续操作，既节省性能又安全。比如在批量查询接口中，发现第一条数据校验失败，没必要继续发送请求，直接 break 还能给用户即时反馈，这种体验是 forEach 给不了的。

这里有个容易被忽视的深坑：异步操作。很多开发会在 for...of 循环里直接写 async/await，本以为能让请求并发执行，实际上它们依然是串行等待的。每一个 iteration 都要等上一个函数 await 完成才会进入下一步。如果追求高并发，得把 await 挪出来用 Promise.all 包裹整个迭代结果；如果只是简单的逐个处理防止超时，那么 for...of 的串行特性反而是个保护伞，避免瞬间把服务器流量打爆。

除了原生数组，还有一个高频场景值得提一提：解构赋值。在遍历包含复杂结构的对象数组时，直接在头部分割变量非常清爽。比如 for (const { name, age } of userList)，代码读起来就像在说人话，避免了每次循环里都重复写 user.name，维护起来也少出错。不过要注意，普通的 Plain Object（纯对象）是不能直接用 for...of 的，这算是它的硬性限制。遇到对象遍历，要么先用 Object.entries() 转换，要么老老实实回退到 for...in 或 Object.keys，这点灵活性不如前者，但也避免了意外遍历到原型链上的脏数据。

从另一个角度看，for...of 其实是向底层生成器（Generator）敞开的大门。虽然前端业务用得少，但当你的数据源来自异步流或者自定义的迭代器时，它是唯一能无缝衔接的方式。这让代码的可扩展性变强，即便未来数据结构变了，只要迭代协议没变，遍历逻辑就不用大改。

工具的选择决定了代码的健壮度。for...of 不是万能的，但在处理值序列、需要中断控制以及兼容性允许的现代浏览器环境中，它确实优于老式的 for 循环。别为了省事一直用 forEach，根据场景灵活切换，才能让那些看似枯燥的循环逻辑变得清晰且高效。下次遇到需要中途跳出的场景，不妨想想这个简洁有力的语法糖，或许能省下一大段防御性的判断代码。