every空数组返回true是逻辑定义而非bug；需长度判断实现“存在且全部满足”；回调必须显式返回布尔值；遇false短路停止；语义上“全真才真”，勿与some混淆。
every 用错地方：它不处理空数组的“预期失败”
很多人以为 every 在空数组上会返回 false，结果发现它返回 true——这不是 bug，是逻辑定义：「所有元素都满足条件」在没有元素时默认成立（空真，vacuous truth）。实际中容易误判业务语义，比如「至少有一个用户已激活」却用 every 去检查 isActive，空列表反而通过校验。
- 空数组调用
every必然返回true，和语言无关（JS、Python 的all()同理） - 若业务要求「存在且全部满足」，得先加长度判断：
arr.length > 0 && arr.every(...) - 常见踩坑场景：表单校验、权限批量检查、数据完整性断言
回调函数里别漏掉 return，否则 every 总是 true
every 的回调必须显式返回布尔值。如果忘了 return，或返回了 undefined、null、0 等 falsy 值，every 会当成 false 处理——但更隐蔽的问题是：箭头函数单表达式体隐式返回，多语句却不自动返回。
- 错误写法：
arr.every(x => { x > 0; })→ 每次返回undefined→ 整个结果为false - 正确写法：
arr.every(x => x > 0)或arr.every(x => { return x > 0; }) - 调试技巧：在回调里加
console.log，确认每次是否真返回了布尔值
every 和 for 循环性能没差别，但短路行为要心里有数
every 遇到第一个 false 就停止遍历，这点和手写 for + break 一致。它不是“全量扫描后汇总”，所以别担心性能拖累；但反过来，如果想强制执行副作用（比如打日志、发请求），every 不适合——它可能中途退出，后续元素根本不会进回调。
- 适合场景：校验、断言、守卫条件（如
if (items.every(isValid)) { ... }） - 不适合场景：需要遍历全部元素做 side effect，改用
forEach或传统for - 参数顺序固定：
(element, index, array)，别把index当成第一个参数来解构
和 some 搞混？记住口诀：“全真才真，一真就真”
every 是「全真才真」，some 是「一真就真」。两者常被拿来做反向替代，比如误用 !arr.some(x => !condition) 代替 arr.every(condition)。语法等价，但可读性差，还多一层取反，debug 时容易绕晕。
- 直接用
every更直白，语义清晰，也少一个括号层级 - 注意
some同样对空数组返回false，和every的true形成对称陷阱 - 复杂条件建议抽成独立函数：
arr.every(isInDateRange)，比内联箭头更易测、易复用
some 的语义边界——这四点漏掉任何一环，every 就容易变成“看似在判断，实则在放行”的隐形漏洞。
