JavaScript类型转换的核心是“何时、依何规则、按何顺序”转换：隐式转换发生在==、+、!、if等场景，显式转换用Number()、String()、Boolean()等，但规则不对称且部分反直觉。
JavaScript 的类型转换不是“要不要转”的问题，而是“什么时候、以什么规则、按什么顺序转”的问题——隐式转换藏在比较、加法、逻辑运算里，显式转换靠 Number()、String()、Boolean() 或一元 +、!! 等操作触发，但它们的规则并不对称，且部分行为反直觉。
哪些操作会触发隐式转换？
不是所有运算都强制转类型，但以下场景一定会走抽象操作（ToPrimitive、ToNumber、ToString 等）：
-
==（双等号）比较时，若两边类型不同，会按抽象相等算法尝试转换：比如0 == false为true，因为false先转成0；"0" == false也成立，因为"0"→0，false→0 -
+运算符：只要一边是字符串，就全部转字符串拼接；否则全转数字相加。所以1 + "2"是"12"，但1 + true是2（true→1） -
!和!!：先将操作数转布尔值（falsy 值包括0、""、null、undefined、NaN、false），再取反 -
if、while、三元条件中的判断表达式：都会调用ToBoolean
显式转换有哪些可靠写法？
手动转类型时，优先选语义明确、行为稳定的方案，避开歧义操作：
- 转数字：
Number("123")最安全（遇到无效字符返回NaN）；parseInt("123px")适合带单位的提取，但注意默认十进制需传10；一元+"123"简洁但不报错，+"abc"直接得NaN - 转字符串：
String(123)和123 + ""效果一致，但前者更易读；避免用.toString()对null或undefined调用，会报错 - 转布尔：
Boolean(0)或!!0都行，但!!更常见；注意"false"、"0"这类非空字符串转布尔仍是true
为什么 [] == ![] 是 true？
这不是 bug，是规范定义的执行路径叠加结果：
立即学习“Java免费学习笔记（深入）”；
- 右边
![]：先对空数组调用ToBoolean→true，再取反 →false - 左边
[] == false：false先转数字得0；[]调用ToPrimitive（默认 hint 是"number"），内部执行valueOf()返回[]（非原始值），再调用toString()→""；""转数字得0 - 于是变成
0 == 0→true
这个例子说明：隐式转换链条长、步骤多，且每一步都有严格优先级，不能靠“感觉”推测。
实际开发中该怎么做？
别依赖隐式转换做关键逻辑判断：
- 比较用
===替代==，杜绝类型转换带来的意外 - 接收外部输入（如表单值、URL 参数）后，立刻用
Number()或parseInt()显式转，并检查isNaN() - 对象转字符串拼接前，确认字段存在且非
null/undefined，否则obj.name + "!"可能产出"null!" - 写工具函数时，用
typeof或Object.prototype.toString.call()做类型校验，而不是靠==猜类型
最麻烦的不是记清所有 ToXXX 规则，而是记住：每个 +、每个 ==、每个 if 条件，背后都可能藏着三次抽象操作和两次类型 fallback。
