JavaScript隐式转换有明确规则但易被忽视：==、+、布尔上下文等会自动触发类型转换，导致意外结果；显式转换应选语义匹配的API，如Math.trunc()、Number.isFinite()、String()等。
JavaScript 的类型转换不是“隐晦”，而是有明确规则——只是这些规则在不同上下文中自动触发，容易让人误以为是魔法。真正的问题在于：你没意识到某个操作正在触发转换，或者记混了 == 和 ===、Number() 和 parseInt() 的行为差异。
哪些操作会触发隐式转换？
隐式转换发生在 JavaScript 引擎“需要”一个特定类型却得到另一个类型时，比如比较、拼接、逻辑运算。它不报错，但结果常出人意料。
==（抽象相等）会先尝试转换两边为同一类型再比较，0 == false为true，'' == 0也为true-
+运算符：任一操作数为字符串，就转为字符串拼接；否则转为数字相加。所以1 + '2'是'12'，但1 + []是'1'（空数组转为空字符串） -
!x和if (x)等布尔上下文，会调用ToBoolean规则：只有false、0、-0、0n、''、null、undefined、NaN为 falsy，其余（包括{}、[]、new Boolean(false)）都是 truthy
Number()、parseInt()、parseFloat() 的区别在哪？
三者都用于字符串转数字，但策略完全不同，混用会导致静默截断或 NaN。
-
Number(' 42 ')→42；Number('42px')→NaN（全匹配，不忽略后缀） -
parseInt('42px', 10)→42；parseInt('0x2A')→42（支持进制，遇到非法字符即停止） -
parseFloat('3.14px')→3.14；parseFloat(' 2e3 ')→2000（只解析开头浮点数，支持科学计数法） - ⚠️
parseInt('08')在非严格模式下可能返回0（老版本当八进制），必须显式传10作为第二参数
如何安全地做显式转换？
显式转换的目标是可预测、可调试。关键不是“怎么写”，而是“选哪个 API 符合语义”。
- 要转成整数且丢弃小数？用
Math.trunc()（不四舍五入，也不进制转换），不是parseInt() - 要验证输入是否为有效数字？优先用
Number.isFinite(x)，而不是!isNaN(x)（后者对空字符串、{}都返回true） - 要字符串化任意值？
String(x)比x + ''更明确；JSON.stringify(x)适合结构化输出，但不处理函数、undefined、Symbol - 要避免
==的陷阱？一律用===，必要时先统一类型：String(a) === String(b)或Number(a) === Number(b)
为什么 [] + [] 是空字符串，而 [] + {} 是 '[object Object]'？
这是对象到原始值转换（[[ToPrimitive]]）规则的直接体现：+ 运算符对对象会先调用 valueOf()，失败再调用 toString()。数组的 valueOf() 返回自身（仍是对象），所以降级到 toString() → ''；而普通对象的 toString() 返回 '[object Object]'。
console.log([] + []); // ''
console.log([] + {}); // '[object Object]'
console.log({} + []); // '[object Object]'（同上，顺序不影响调用逻辑）
console.log([1,2] + [3,4]); // '1,23,4'（数组 toString 返回逗号分隔字符串）
最易被忽略的点：隐式转换不只发生在初学者代码里。它藏在 switch 的 case 匹配、Map 键的相等性、甚至 React 的 key 渲染逻辑中。一旦依赖自动转换，问题往往出现在边界数据（如后端返回的 "0" 字符串 vs 数字 0）上，而且难以复现。
