别再用 for 循环做验证了，JS 的 every 能帮你省下一半代码

在后台管理系统里，我们最常遇到的场景之一便是数据校验。比如收到一个订单列表，需要确认所有订单是否都已支付；或者在提交表单前，检查一行配置项里的所有字段是否都符合特定格式。

早年写代码时，习惯性地会先初始化一个 bool 变量，然后写一个 for 循环遍历数组，一旦发现不满足条件的就标记为 false 并跳出。代码写得长不说，维护起来还累赘。其实，JavaScript 原生提供的 Array.prototype.every() 方法，就是专为这种“全员达标”的场景设计的。

它的逻辑非常直白：只有当数组中的每一个元素都通过测试函数的判定时，才返回 true，只要有一个失败，立马返回 false。

举个例子，假设我们要判断购物车里的商品库存是否充足：

const cart = [
  { id: 101, stock: 5 },
  { id: 102, stock: 2 },
  { id: 103, stock: 10 }
];

const allInStock = cart.every(item => item.stock > 0);
console.log(allInStock); // true

这段代码读起来就像人话：“购物车里所有商品的库存是不是都大于 0？”比起传统的 for 循环，意图清晰得多，也减少了人为编写索引变量的出错概率。

这里必须提一下 every 最核心的优势：短路机制。一旦回调函数对某个元素返回了 false，整个方法就会立即停止后续遍历，直接返回 false。这意味着如果数组有 1 万个数据，但第 3 个就出错了，它不会浪费时间去检查剩下的 9997 个。在处理大数据量或网络请求延迟较高的场景中，这种性能优化是实打实的。

不过，用这套 API 之前，有个特别容易踩的坑需要留意，那就是空数组的处理。数学上规定“空集中所有元素都满足性质”为真，所以 [] .every(() => false) 的结果竟然是 true。如果你没有预先判断数组长度，直接拿去控制业务逻辑，可能会导致本该拦截的无效操作通过了验证。解决思路很简单，在调用 before 加上 arr.length > 0 && arr.every(...) 的判断，就能稳妥地规避这个问题。

很多人会问，既然要验证，为什么不用 filter 过滤出失败的再判断长度？从效率上看，filter 无论结果如何都会遍历完整个数组，生成一个新数组，而 every 遇到第一个失败项就停下，且不需要分配新内存。除非你需要同时获取那些不符合条件的项目列表，否则单纯做布尔值验证，every 是更优解。反过来，如果你想找“是否存在”符合条件的项，用 some 会更合适，它们是孪生兄弟，各司其职。

掌握这些细节后，你会发现前端代码的简洁度提升了不少。工具和方法本身没有优劣，关键在于你是否理解它们背后的运行机制。下次再面对全员校验的需求时，不妨把那个冗长的 for 循环删掉，试试 every，让代码更像是在表达意图，而不是在堆砌逻辑。毕竟，好代码的标准之一就是让人一眼就能看懂你在做什么，而不是猜你写了多少行。