如果你翻阅过 Google、Airbnb 或其他任何一家顶级科技公司的前端代码规范，几乎总能看到一条规定：禁止使用 ==。
==（宽松相等）和 ===（严格相等）不都用来判断相等吗？为什么非要对一个双等号赶尽杀绝？
然而，在成千上万行代码、数百人协作的大型项目中，这个看似微小的选择，恰恰是保证代码质量、可维护性和团队协作效率的基石。
无法预测的“隐式类型转换”
要理解为什么 == 是“魔鬼”，我们必须先弄懂它和 === 的根本区别。
===简单、纯粹且可预测，它只比较两个值是否在类型和值上都完全相等。5 === 5 // true '5' === 5 // false (类型不同) true === 1 // false (类型不同) null === undefined // false (类型不同)==在比较之前，它会尝试将两个操作数转换成相同的类型（即隐式类型转换），然后再进行值的比较。'5'== 5 // true(字符串 5 号被转换为数字 5) true == 1 // true(布尔值 true 被转换为数字 1) false == 0 // true(布尔值 false 被转换为数字 0) ''== false // true (空字符串被转换为数字 0)
问题就出在这个“隐式类型转换”上。它的转换规则复杂且反直觉，是 JavaScript 中最臭名昭著的“坑”之一。
== 的诡异行为
让我们来看几个经典的例子，感受一下 == 带来的“惊喜”：
1. “假值”的混乱
在 JavaScript 中，false, 0, '' (空字符串), null, undefined 都是“假值”，但在 == 的世界里，它们的关系错综复杂。
false == 0; // true
false == ''; // true
0 == ''; // true
// 但是...
null == false; // false
undefined == false; // false
null == 0; // false当你试图用 if (value == false) 来判断一个值是否为“假”时，null 和 undefined 会出人意料地“逃脱”，极易导致逻辑漏洞。
2. 数组和对象的“变形记”
当对象（包括数组）与原始类型使用 == 比较时，JavaScript 会尝试调用对象的 toString() 或 valueOf() 方法，将其转换为原始类型。
[10] == 10; // true(数组[10]调用 toString()变为 '10'，再转为数字 10)
[] == 0; // true(数组[]调用 toString()变为'', 再转为数字 0)
[]== ![]; // true(右边![]变为 false，于是变成[]==false，最终为 true)
'0'== false; // true(右边 false 转为 0，左边'0'转为 0)最后这个 [] == ![] 的结果，足以让任何一个试图凭直觉写代码的开发者怀疑人生，这种代码不仅难以阅读，更是在代码审查中引发灾难的源头。
有一个广为人知的 == 使用技巧：x == null，这行代码等价于 x === null || x === undefined，可以方便地同时检查 null 和 undefined。
虽然这是 == 为数不多的“有用”之处，但绝大多数严格的代码规范依然选择禁用它。原因很简单：为了规则的绝对一致性。写 x === null || x === undefined 虽然长一点，但它的意图清晰明确，没有任何歧义。
总而言之，在代码中禁用 ==，并非出于偏执，而是一种防御性编程的体现。
它背后的核心思想是：在软件工程中，可预测性远比所谓的“便捷”或“智能”更重要。