JavaScript类型检测需组合使用:typeof对null返回"object"是历史bug,应配合value===null判断;精确识别内置对象须用Object.prototype.toString.call()和Array.isArray();隐式转换易出错,推荐严格相等和显式转换。
JavaScript 有 7 种原始(primitive)类型和 1 种引用(object)类型,但实际运行中类型检查和转换行为常让人困惑——关键不在“有哪些”,而在“typeof、instanceof、Object.prototype.toString.call() 各自能信多少”。
null 和 undefined 的 typeof 返回值是历史包袱typeof 对大部分原始类型返回预期结果,但有两个经典例外:
typeof null 返回 "object"(V8 引擎早期 bug,沿用至今)typeof undefined 返回 "undefined"(正确)typeof Symbol("a") 返回 "symbol"(ES6 新增,正常)typeof 42n(BigInt)返回 "bigint"(ES2025 起支持)所以不能单靠 typeof 判定是否为对象或 null。遇到 "object",必须再用 value === null 单独排除。
Array.isArray() 和 Object.prototype.toString.call() 是最可靠的类型探测组合当需要精确区分 Array、Date、RegExp、Map 等内置对象时,instanceof 在跨 iframe 或不同全局环境会失效;typeof
统一返回 "object"。
此时应优先使用:
Object.prototype.toString.call([]) // "[object Array]" Object.prototype.toString.call(new Date()) // "[object Date]" Object.prototype.toString.call(/a/g) // "[object RegExp]" Object.prototype.toString.call(null) // "[object Null]" Object.prototype.toString.call(undefined) // "[object Undefined]"
配合 Array.isArray()(专用于数组,更语义化且性能略优)即可覆盖绝大多数场景。
==、+、! 和 if 条件判断JavaScript 在特定操作符下会自动调用 toString() 或 valueOf(),导致反直觉结果:
0 == false → true(false 转为 0)"" == false → true(空字符串转为 0,再与 false 比较)[] == ![] → true(右边先转布尔 true,再取反为 false;左边转为空字符串 "",再转为 0;0 == false 成立)[1] + [2] → "12"(两个数组先 toString() 得 "1" 和 "2",再字符串拼接)建议:永远用 === 替代 ==;对用户输入或外部数据做类型校验时,显式调用 Number()、String()、Boolean(),而非依赖隐式转换。
Number()、parseInt()、parseFloat() 行为完全不同三者都可用于字符串转数字,但规则差异极大:
Number(" 42 ") → 42(前后空格被忽略,全字符串必须可解析)Number("42px") → NaN(任何非纯数字字符都会失败)parseInt("42px") → 42(从左开始解析,遇到非法字符即停)parseInt("0x1A") → 26(支持进制前缀,0x 表示十六进制)parseFloat("3.14e2") → 314(支持科学计数法,只解析开头浮点部分)若目标是“安全提取数字”,优先用 Number();若需兼容带单位或前缀的字符串,才考虑 parseInt() 或 parseFloat(),并始终检查返回值是否为 NaN(注意:NaN !== NaN,要用 isNaN() 或 Number.isNaN())。
类型检查真正难的不是记住所有方法,而是意识到「JS 类型系统本质是运行时、弱且动态的」——没有编译期类型约束,所有检查都是补救。最容易被忽略的是跨环境对象识别(比如 iframe 中的数组)和 null 的双重身份(原始值却返回 "object")。写工具函数时,别省那几行 value === null 或 Object.prototype.toString.call(value)。