显式转换需谨慎选择函数：优先用Number()转数字，String()转字符串；BigInt与Number不可隐式转换，混用会报错；JSON.parse非通用类型转换工具。
显式转换必须用对函数，否则结果反直觉
JavaScript 中最常用的显式转换是 Number()、String()、Boolean() 和 parseInt()/parseFloat()。它们行为差异很大，尤其在处理边缘值时：
-
Number(" 012 ")→12（自动 trim 并按十进制解析） -
parseInt("012")→12（ES5+ 默认为 10 进制，但旧环境可能当八进制） -
Number("")→0，而Boolean("")→false，String(0)→"0" -
Number("abc")→NaN，但parseInt("abc")→NaN，parseFloat("abc")→NaN—— 看似一致，可一旦换成"123abc"就不同：parseInt("123abc")→123，Number("123abc")→NaN
推荐优先用 Number() 做字符串→数字转换，除非明确需要截断非数字后缀；用 String(value) 而非 "" + value，语义更清晰且避免隐式触发。
隐式转换发生在 ==、+、!、if 等上下文中，规则难记易错
隐式转换不透明，依赖抽象操作 ToPrimitive、ToNumber、 的组合，常见陷阱包括：</code.tostring></p>
<ul>
<li>
<code>[] == ![] → true：左边空数组转原始值为 ""，右边先 ![] → false，再 == 比较 "" == false → 都转成 0 → true
[1] + [2] → "12"：+ 遇到任一操作数是字符串，就全部转字符串拼接；但 [1] - [2] → -1：减法强制转数字if ({}) → 执行分支，因为对象是真值；但 if ([]) 同样执行分支，尽管 [] == false 是 true —— 注意：真值判断和相等比较用的是两套规则永远用 === 替代 ==，禁用 == null 判空（改用 value == null 仅在需同时捕获 null 和 undefined 时可接受，但应写注释说明意图）。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
JSON.parse / JSON.stringify 不是类型转换工具，会抛错或静默丢失
有人用 JSON.parse(JSON.stringify(x)) “深拷贝”或“标准化类型”，但这本质不是类型转换，且风险极高：
-
JSON.stringify(new Date())→"2024-01-01T00:00:00.000Z"，再JSON.parse得到字符串，不是Date对象 -
JSON.stringify(/regex/)→null，JSON.stringify(undefined)→ 字符串中直接丢弃该字段 -
JSON.stringify({a: () => {}})→"{}"，函数被忽略 -
JSON.parse("123")→123（数字），但JSON.parse("true")→true（布尔），JSON.parse("null")→null—— 它只识别合法 JSON 字面量，不是通用字符串转类型工具
若需从字符串还原结构化数据，应约定格式（如带类型标记的 JSON Schema），或用专用解析器，别依赖 JSON API 做类型推断。
BigInt 与 Number 混用会直接报错，不能隐式转换
BigInt 是独立类型，和 Number 之间无隐式转换，连 == 都不兼容：
1n == 1 // TypeError: Cannot mix BigInt and other types, use explicit conversions 1n === 1 // false Number(1n) // 1 BigInt(1) // 1n
更危险的是 +、-、* 等运算符，只要一边是 BigInt，另一边不是同类型，就立即抛 TypeError。数据库 ID、时间戳高精度场景若引入 BigInt，必须全链路保持类型一致，后端返回 JSON 中的数字若超过 2^53 - 1，前端收到已是字符串，需手动调用 BigInt(str) —— 且得确保所有消费方都知情并适配。
类型转换从来不是“多一行代码就搞定”的事，它牵扯运行时行为、跨环境兼容、甚至安全边界。显式调用哪个函数、是否校验 NaN 或 null、是否要 fallback，每个选择都在定义你的程序如何面对意外输入。
