17370845950

JavaScript隐式类型转换只发生在特定操作符或上下文中，如==、+、!、if/while/for条件判断及函数参数传入时；===和显式转换如Number()不触发隐式转换。

JavaScript 中的隐式类型转换到底在哪儿发生

隐式转换不是“全局开关”，它只发生在特定操作符或上下文中。最常见的是 ==、+、!、if 条件判断、while、for 的条件部分，以及函数参数传入时（但不包括严格相等 === 或显式调用如 Number()）。

比如：if (0) 会转成 false，"" + 123 会把 123 转成字符串拼接，而 0 == false 触发抽象相等算法，两边都转成数字再比——false 变 0，所以结果是 true。

为什么 [] == ![] 是 true

这个经典例子暴露了抽象相等（==）的执行顺序和优先级陷阱：

• ![] 先执行：空数组是真值 → ![] 得 false
• [] == false：右边是布尔值，按规则转成数字 → false → 0
• [] == 0：左边是对象，先调用 valueOf()（返回 []）→ 再调用 toString() → [] 的 toString() 返回空字符串 ""
• "" == 0：字符串转数字 → "" → 0 → 0 == 0 → true

整个过程没有报错，但每一步转换都依赖规范定义，人脑很难即时还原。

Number()、parseInt() 和一元加号 + 的行为差异

三者都常被用来“转数字”，但处理方式完全不同：

• Number(" 123 ") → 123（前后空白自动忽略，全字符必须可解析）
• Number("123abc") → NaN（不允许任何多余字符）
• parseInt("123abc") → 123（从左开始解析，遇到非法字符就停）
• +"123abc" → NaN（行为同 Number()，不是 parseInt()）
• parseInt("08") 在老引擎中可能当八进制（得 8），ES5+ 默认是十进制，但显式写 parseInt("08", 10) 更安全

console.log(Number("123px"));    // NaN
console.log(parseInt("123px"));  // 123
console.log(+"123px");         // NaN

对象到原始值的转换规则容易被忽略

几乎所有涉及对象参与的隐式转换（比如 obj == 123、obj + "str"、String(obj)），都会触发内部的 [[ToPrimitive]] 操作。它按顺序尝试：

• 先调用 obj.valueOf()，如果返回原始值（string/number/boolean/null/undefined），就用它
• 否则调用 obj.toString()，如果返回原始值，就用它
• 否则抛 TypeError

内置对象有默认实现：比如 new Date() 的 valueOf() 返回时间戳（数字），toString() 返回日期字符串；而 [] 的 valueOf() 返回自身（对象），toString() 返回 ""；{} 的 toString() 返回 "[object Object]"。

自定义对象若没重写这两个方法，就容易在 == 或 + 中表现得难以预测。

真正麻烦的不是“怎么转”，而是“谁在什么时候悄悄帮你转了”。只要用了 ==、+、if、||、&&，转换就在发生——而且规则嵌套深、例外多。写代码时宁可用 ===、Boolean(x)、String(x)、Number(x) 显式控制，也别依赖 JS 自己猜你想要什么。