JavaScript隐式类型转换发生在==、&&、||、!、if、while及+等场景，按抽象操作规则自动转换类型；==触发抽象相等算法并转换类型，===则严格比较类型与值，不转换。
JavaScript 中的隐式类型转换发生在什么时候
当使用 ==、&&、||、!、if 条件判断、while 循环、甚至字符串拼接（+）时，JavaScript 会按抽象操作规则自动转换类型。这不是“bug”，而是语言设计的一部分，但极易引发意外行为。
比如 0 == false 返回 true，因为 false 被转为 0；"0" == false 也返回 true，过程是：false → 0，再把 "0" 转成数字 0，最后比较 0 == 0。
-
null == undefined是唯一被特殊规定为true的非相等值对（其他所有比较都走 ToNumber/ToString 转换） -
NaN == NaN永远为false，哪怕显式转成数字也没用 -
[] == ![]返回true：左边空数组转字符串为""，再转数字为0；右边先取反（[]转布尔为true，取反得false），再转数字为0
== 和 === 的核心区别只在是否触发抽象相等比较
== 执行「抽象相等算法」（Abstract Equality Comparison），会在比较前尝试类型转换；=== 执行「严格相等算法」（Strict Equality Comparison），只要类型不同就直接返回 false，不转换。
这意味着：0 === false 是 false（类型不同），而 0 == false 是 true（都转成数字后相等）；"1" === 1 是 false，但 "1" == 1 是 true。
立即学习“Java免费学习笔记（深入）”；
- 遇到
null或undefined：只有null == undefined为true，其余如null == 0、undefined == ""全为false - 对象与原始值比较（如
[1] == 1）：对象先调用valueOf()，失败再调用toString()，得到原始值后再参与转换 -
===并非“更快”，只是跳过转换步骤——性能差异在现代引擎中可忽略，关键在于语义可控
哪些场景还可能偷偷触发类型转换
除了 ==，这些地方也容易忽略隐式转换：
-
Boolean构造函数或!!：传入"0"、"false"、[]、{}都会得到true（它们都是“真值”） -
+运算符：若任一操作数是字符串，则全部转字符串拼接；否则全转数字相加。所以1 + "2"是"12"，而1 + +"2"是3 -
switch使用的是===，但case表达式本身可能产生副作用（比如调用函数返回不同类型的值） -
JSON.stringify()对undefined、function、symbol会静默丢弃，而JSON.parse()只接受字符串，传错类型会直接抛SyntaxError
如何避免被类型转换坑到
不是靠死记规则，而是建立检查习惯：
- 永远优先用
===和!==；仅在明确需要宽松比较时（例如兼容旧接口接收"1"或1）才用== - 处理用户输入或 API 数据时，尽早显式转换：
Number(str)而非+str（后者对空格、" "等返回0），String(val)而非val + "" - 用
Object.is(a, b)替代===处理边缘情况：它能正确区分+0和-0，且Object.is(NaN, NaN)返回true
if (value != null) { /* 错误：会把 0、""、false 当作 null */ }
if (value !== null && value !== undefined) { /* 正确 */ }
if (value == null) { /* 可接受：这是唯一推荐用 == 的地方，等价于 null/undefined 判定 */ }类型转换本身没有问题，问题出在预期和实际不一致。真正难的不是记住 "0" == false 是 true，而是意识到你在某个 if (input == 1) 里，其实悄悄把字符串、数字、甚至对象都混在一起比了。
