JavaScript类型转换核心在于明确隐式与显式转换场景及规则:==等操作触发隐式转换易致bug;Number/parseInt/parseFloat转换逻辑各异;安全判断需用Array.isArray、===等显式方法;JSON序列化会静默丢失undefined、BigInt等类型。
JavaScript 类型转换不是“要不要转”的问题,而是“什么时候隐式转、什么时候显式转、谁在替你转”的问题。多数 bug 不来自不会转,而来自没意识到正在被转。
JavaScript 在 ==、&&、||、+、!、if 条件判断等场景下会自动

ToPrimitive 或 ToNumber 等抽象操作,结果常出人意料。
0 == false → true(false 被转成 0)"0" == false → true(两边都转成 0)[] == ![] → true(空数组转为 "",再转为 0;![] 先转布尔得 false,再转数字得 0){} + [] → "[object Object]",但 [] + {} → "[object Object]"(顺序影响调用 toString 还是 valueOf)Number()、parseInt()、parseFloat() 的区别
三者都用于字符串转数字,但规则完全不同,混用极易丢数据或得 NaN。
Number(" 012 ") → 12(严格解析,前后空格可忽略,但不支持进制;遇到非数字符立即返回 NaN)parseInt("012", 10) → 12(必须显式传 radix,否则旧浏览器可能按八进制解析 "012" 得 10)parseInt("12.99") → 12(只取开头有效整数部分,小数点后全截断)parseFloat("12.99abc") → 12.99(同上,但支持小数)Number("12.99abc") → NaN(整个字符串必须可完整转为数字)别依赖 typeof 判断数组或 null,也别靠 == null 检查空值 —— 显式、分步、带边界校验才是可靠做法。
value === null || value === undefined,或直接 value == null(仅当明确接受两者等价时)Array.isArray(value),不用 typeof value === "object" 或 value.constructor === Array
String(value).trim(),再用 Number(),最后检查 !isNaN(result) && isFinite(result)
!!value:它把 "0"、"false"、[] 都转成 true;真要语义化布尔,请写 value === "true" || value === true || value === 1 这类明确逻辑它们看似只是序列化工具,但内部会触发类型转换,尤其在处理 Date、undefined、function、BigInt 时静默丢失数据。
JSON.stringify({ time: new Date() }) → {"time":"2025-05-20T12:00:00.000Z"}(Date 自动调 .toISOString())JSON.stringify({ x: undefined }) → {}(键值为 undefined 被完全忽略)JSON.parse('{"x": 123}')["x"] → 123(永远是 JS 原生类型,不会保留字符串引号)JSON.stringify(BigInt(123)) → 报错 TypeError: Do not know how to serialize a BigInt
如果接口返回的是时间字符串但前端需要 Date 实例,别指望 JSON.parse() 自动帮你转 —— 必须手动映射。