17370845950

== 会偷偷改数据类型，因其先进行隐式转换再比较值，如 null == undefined 为 true、'0' == false 为 true；=== 则严格先判类型再比值，避免意外转换，是日常开发首选。

什么时候 == 会偷偷改你的数据类型？

== 不是“看值一样就放行”，而是“先动手改类型，再比值”。它有一套隐式转换规则，很多 bug 就藏在这些自动转换里。

• null == undefined 返回 true，但两者语义完全不同：一个是“有意为空”，一个是“未定义”
• '0' == false 是 true——字符串转成数字 0，再和布尔转成的 0 比，全被“搓平”了
• [] == false 也是 true：空数组 valueOf() 得到空字符串 ''，再转成数字 0，等于 false 转来的 0
• 对象参与 == 比较时（如 {a:1} == '[object Object]'），会调用 toString() 或 valueOf()，结果不可控

为什么 === 才是日常开发的默认选择？

=== 的逻辑极其干净：类型不同 → 直接 false；类型相同 → 再比值。没有例外，不猜你意图。

• 避免意外转换：0 === ''、0 === false、'1' === true 全是 false，一眼可知类型不匹配
• 函数参数校验更可靠：比如写 if (id === null)，不会误把 undefined 或字符串 "null" 放过去
• 与 TypeScript 协作更顺：TS 编译期能推断类型，=== 的行为和类型系统完全对齐
• 性能略优：跳过类型转换步骤，尤其在循环或高频判断中可感知

哪些场景下 == 真的有用？

极少，但存在。只在你**明确依赖类型宽松性**且已充分测试时才考虑。

• 检查用户输入是否为“空值等价物”：if (input == null) 可同时捕获 null 和 undefined（但更推荐用 input == null || input == undefined 或直接用可选链）
• 与 DOM API 交互时：某些老接口返回字符串或数字混用（如 el.getAttribute('data-id') 是字符串，但你想和数字 5 比），这时 == 确实省事——但更稳妥的是显式转换：Number(el.getAttribute('data-id')) === 5
• 注意：== 在数组/对象比较中毫无意义：[1] == '1' 是 true，但 [1] === '1' 是 false，而你几乎从不需要这种“数组转字符串再比”的逻辑

容易被忽略的 === 边界情况

别以为 === 就万事大吉——两个看似一样的值，仍可能因底层表示不同而失败。

• NaN === NaN 是 false：这是唯一一个自己不等于自己的值，必须用 isNaN(x) 判断
• +0 === -0 是 true，但它们在某些数学运算中表现不同（如 1 / +0 是 Infinity，1 / -0 是 -Infinity）；需严格区分时用 Object.is(+0, -0)
• 字符串字面量 vs 字符串对象：'abc' === new String('abc') 是 false（后者是对象类型），哪怕 == 会把它转回来
• 两个内容相同的对象永远不 ===：{a:1} === {a:1} 是 false，因为引用不同——深比较要用 JSON.stringify 或专用库

console.log(NaN === NaN);        // false
console.log(Object.is(NaN, NaN)); // true
console.log(+0 === -0);          // true
console.log(Object.is(+0, -0));   // false

类型转换不是魔法，是隐藏的执行路径；而 === 把判断权交还给你——哪怕多写一个 Number() 或 String()，也好过靠记忆去猜 == 下一步会怎么 coerce。