ESLint规则冲突：unicorn/no-array-for-each与no-restricted-syntax如何选择？

这确实是个挺常见的ESLint规则冲突场景，我来分享下我的实践经验和判断逻辑——其实没有绝对的「更合理」，核心得看你的项目需求、团队技术风格和运行环境：

先搞懂两个规则的核心诉求 #

• unicorn/no-array-for-each：
  它的出发点是for…of的灵活性和性能优势：

  • 支持break/continue/return提前终止循环，这是forEach做不到的（forEach只能通过抛出异常强行终止，非常反直觉）；
  • 理论上for…of的执行速度比forEach更快（现代JS引擎下小数组差异不大，但超大数组场景会有明显区别）。

• no-restricted-syntax（针对for…of的限制）：
  它的核心顾虑是两个：

  • 某些环境下for…of可能需要引入regenerator-runtime依赖，增加包体积，对老项目、轻量前端页面或者小程序这类对体积敏感的场景不友好；
  • 偏好声明式的函数式编程风格，认为forEach/map这类数组方法的代码更简洁、意图更明确，而命令式的for循环显得笨重。

根据场景做选择 #

场景1：需要提前终止循环 #

如果你的代码经常需要在迭代过程中break（比如找到第一个符合条件的元素就停止）、continue跳过某些项，或者在函数里通过return终止迭代，那优先启用unicorn/no-array-for-each，同时修改no-restricted-syntax规则，把ForOfStatement从限制列表中移除。

毕竟forEach天生不支持中断，硬要实现类似逻辑只会写出晦涩的代码，比如：

// 反例：用forEach模拟break，非常别扭
let found = false;
itemList.forEach(item => {
  if (found) return;
  if (item.a > 1) {
    found = true;
    return;
  }
  console.log(item.a);
});

// 用for…of就清晰很多
for (const item of itemList) {
  if (item.a > 1) break;
  console.log(item.a);
}

场景2：对包体积/兼容性敏感 #

如果你的项目运行在旧浏览器（比如IE11及以下）、小程序这类环境，或者非常在意包体积（比如纯静态营销页面），而且不需要提前终止循环，那优先遵循no-restricted-syntax，继续用forEach。

因为for…of在某些打包配置下会触发regenerator-runtime的引入，这部分代码对轻量项目来说确实是冗余的；而forEach是ES5原生方法，兼容性拉满，也不需要额外依赖。

场景3：团队偏好函数式编程风格 #

如果你的团队习惯用函数式编程的思路写代码，偏好forEach/map/filter这类声明式的数组方法，那选no-restricted-syntax的方向更合适。这类代码在不需要中断的场景下，可读性和简洁度确实优于命令式的for循环。

场景4：性能是核心需求 #

如果你的代码需要处理超大数组（比如几万甚至几十万条数据），那可以倾向unicorn/no-array-for-each规则。虽然现代引擎对forEach的优化已经很好，但for…of在极端场景下的性能优势还是存在的。

折中方案：自定义规则 #

如果不想二选一，也可以自定义ESLint配置：

• 在no-restricted-syntax里保留其他限制，但允许ForOfStatement；
• 或者结合eslint-plugin-unicorn的规则，只在需要中断循环的场景允许for…of，其他场景提示用数组方法。

内容的提问来源于stack exchange，提问作者Mike