== 会偷偷改数据类型，因其先进行隐式转换再比较值，如 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，而你几乎从不需要这种“数组转字符串再比”的逻辑
容易被忽略的 === 边界情况
别以为 === 就万事大吉——两个看似一样的值，仍可能因底层表示不同而失败。
立即学习“Java免费学习笔记（深入）”；
-
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。 
