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
整个过程没有报错，但每一步转换都依赖规范定义，人脑很难即时还原。
立即学习“Java免费学习笔记（深入）”；
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 自己猜你想要什么。
