JavaScript类型转换核心在于隐式转换规则：==比较时按固定路径分步转换，Number()、parseInt()和+行为不同，对象转原始值优先调用valueOf()再toString()。
JavaScript 中的类型转换不是“要不要转”的问题，而是“什么时候自动转、怎么手动转、转错时为什么看起来合理却出 bug”的问题。它直接决定 == 是否成立、Boolean() 返回什么、+ 是拼接还是加法——很多看似奇怪的行为，根源都在隐式转换规则里。
为什么 [] == ![] 返回 true？
这不是玄学，是两套隐式转换流程在各自执行：
-
![]先转布尔值：[]是真值 →![]得false -
[] == false触发抽象相等比较：右边false先转数字 →0；左边[]调用toString()→ 空字符串""；再把""转数字 → 还是0 - 最终比较
0 == 0，结果为true
关键点在于：每次比较只按规则走一步转换，不是一次性“猜意图”。== 的转换路径固定，但容易层层嵌套，人脑难追踪。
Number()、parseInt() 和一元加号 + 的区别
三者都常用来转数字，但行为差异极大：
立即学习“Java免费学习笔记（深入）”；
-
Number("123abc")→NaN（整个字符串必须可完整解析） -
parseInt("123abc")→123（忽略后续无法解析的字符，且默认十进制；parseInt("0x10")才得16） -
+"123abc"→NaN（等价于Number()，不是parseInt()） -
parseInt(" 42 ")会忽略首尾空格；Number(" 42 ")也会，但parseInt("42px")得42，Number("42px")得NaN
真实项目中，如果后端返回 "123.00" 这类带小数位的字符串，用 parseInt() 会意外截断成 123；该用 Number() 或 parseFloat()。
对象转原始值：toString() 和 valueOf() 怎么被调用？
当 JS 需要把对象转成字符串或数字时（比如用在 +、==、String() 中），会按固定顺序尝试两个方法：
const obj = {
valueOf() { return 42; },
toString() { return "hello"; }
};
obj + 1 // → 43（先调 valueOf，返回原始值，不再调 toString）
String(obj) // → "hello"（String() 明确要求字符串，跳过 valueOf，直接调 toString）
但注意：valueOf() 必须返回原始值（string/number/boolean/null/undefined），否则 JS 会 fallback 到 toString()；如果两者都返回对象，就抛 TypeError。
自定义类中若想控制转换行为，必须确保这两个方法返回原始值，且逻辑不冲突——比如 valueOf() 返回数值用于计算，toString() 返回描述性字符串用于日志，这是合理分工。
最常被忽略的是：隐式转换发生在你没写任何转换函数的时候。只要用了 ==、+、if 判断、console.log() 输出对象，转换就在发生。看懂它，不是为了背规则，而是下次遇到 [1,2] + [3,4] 得 "1,23,4" 时，能立刻反应过来：这是两个数组先 toString() 成字符串，再拼接。
