javascript类型转换分隐式和显式：隐式由运算符（如==、+、!、if）触发，按规范强制转类型；显式用string()、number()、boolean()等主动转换，更安全可控；==允许隐式转换而===禁止，现代代码应优先用===。
JavaScript 的类型转换不是“按需触发”的智能机制，而是由运算符、语句或函数强制执行的确定性规则。隐式转换常在你没意识到时发生，显式转换则是你主动调用 String()、Number() 或 Boolean() 等函数明确要求的。
哪些操作会触发隐式转换？
隐式转换发生在 JavaScript 引擎为执行运算而必须统一操作数类型时。它不看你的意图，只看规范定义的抽象操作，比如 ==、+、!、if 条件判断等。
-
==会先尝试把两边转成相同类型再比较（"0" == false→true） -
+遇到字符串就全部转字符串拼接（1 + "2"→"12"），但-、*、/一律转数字（"1" - "2"→-1） -
if (x)、while(x)、!x会把x转成布尔值，遵循“falsy 值”规则（""、0、-0、NaN、null、undefined） -
console.log({})会调用toString()，输出[object Object]；但{} + []在非严格模式下会被解释为代码块，实际执行的是+[]→0
显式转换有哪些安全写法？
显式转换是你掌控流程的关键手段，但不同写法行为差异很大，不能混用。
- 转字符串：优先用
String(x)，它对null和undefined返回"null"、"undefined"；x.toString()会报错（null.toString()→TypeError） - 转数字：用
Number(x)最稳妥，它对空字符串返回0，对无效字符串返回NaN；parseInt(x)是解析（忽略后缀、支持进制），不是转换（parseInt("12px")→12，但Number("12px")→NaN） - 转布尔：直接用
Boolean(x)或双重取反!!x，两者行为完全一致；不要用new Boolean(x)，它返回的是对象，始终为真（if (new Boolean(false))会进入分支）
为什么 == 和 === 的区别不只是“多一个等号”？
根本区别在于是否允许隐式类型转换：== 启动抽象相等算法（ToPrimitive → ToNumber/ToString），而 === 要求类型和值都相同，拒绝任何转换。
立即学习“Java免费学习笔记（深入）”；
0 == false // true，因为 false → 0 0 === false // false，类型不同（number vs boolean） <p>"0" == false // true，"0" → 0，false → 0 "0" === false // false</p><p>[] == ![] // true：右边 ![] → false，左边 [] → "" → 0，右边 false → 0，所以 0 == 0 [] === ![] // false
这种看似“便利”的隐式链，实际让逻辑难以追踪。现代代码几乎全部使用 ===，除非你明确需要 == null 这种简写（等价于 x === null || x === undefined）。
最容易被忽略的隐式转换陷阱
很多 bug 不来自语法错误，而是隐式转换在边界值上产生的反直觉结果。
-
Array.prototype.sort()默认按字符串排序：[10, 2, 1].sort()→[1, 10, 2]，因为每个数字先转成字符串再比较 -
JSON.stringify()会忽略undefined、function和Symbol，但如果你的对象里有toString()方法，它可能被意外调用并改变状态 -
new Date() - 0是合法的（返回时间戳），但new Date() + 0是字符串拼接（"Fri Jan 01 2021 00:00:00 GMT+0800 (CST)0"） -
document.getElementById("nonexistent")返回null，而null == undefined为true，但null === undefined为false—— 这直接影响条件判断是否健壮
隐式转换的规则表很长，但真正危险的从来不是“记不住”，而是以为自己知道、却没验证过具体值的行为。
