JavaScript类型判断：从入门到架构设计

JavaScript类型判断不是语法糖，而是运行时逻辑的基石：需区分原始类型（7种，栈存值）与引用类型（Object派生，堆存址），严格选用typeof、instanceof、Array.isArray()、Object.prototype.toString.call()四类方法，封装语义化工具函数并规避null、NaN、跨iframe等陷阱。

JavaScript类型判断不是语法糖，而是运行时逻辑的基石。写错一个typeof或误用instanceof，轻则参数校验失效，重则跨iframe通信崩溃、API解析出错。真正可靠的判断，必须匹配数据本质——是值还是引用？是谁构造的？在哪个执行上下文里？

区分原始类型和引用类型是所有判断的前提

JS只有两类本质：原始类型（栈中存值）和引用类型（栈中存地址）。这个区别直接决定后续方法是否有效：

• 原始类型共7种：string、number、boolean、undefined、null、symbol、bigint；它们不可变，赋值即拷贝
• 引用类型本质都是Object的派生，包括Array、Date、RegExp、Map、Set、Function等；它们可变，赋值传递的是引用
• typeof null返回"object"是历史bug，不能用于判空；NaN属于number类型，但NaN !== NaN，必须用Number.isNaN()

4种核心判断方法各司其职，不能混用

没有“万能方法”，只有“场景适配”：

• typeof：只适合快速识别原始类型（除null）和函数。例如typeof x === 'function'安全，typeof [] === 'object'无意义
• instanceof：判断原型链归属，适用于已知构造器的场景（如date instanceof Date），但在跨iframe时会失效（不同全局环境的Date不相等）
• Array.isArray()：专治数组判断，比instanceof Array更可靠，是ES5标准推荐方式
• Object.prototype.toString.call()：唯一能精准区分所有内置类型的方案，返回"[object Array]"、"[object Null]"等标准字符串，适合通用工具函数

架构级类型判断需要封装与约束

在中大型项目中，裸写typeof或instanceof会带来维护风险。应统一收口：

立即学习“Java免费学习笔记（深入）”；

• 定义isString()、isPlainObject()、isFunction()等语义化工具函数，内部统一用toString.call实现
• 对API响应做类型守卫，例如用isUser(data)断言结构，失败时抛出自解释错误，而非让data.name.toUpperCase()静默报错
• 避免在条件分支中重复判断同一变量，提取为常量：const isDateValid = data && data instanceof Date && !isNaN(data.getTime())
• TypeScript虽在编译期检查类型，但运行时仍需判断——尤其处理JSON.parse()、localStorage读取、第三方SDK回调等动态数据

避开高频陷阱：null、NaN、跨域对象、包装对象

这些细节不处理，上线后就是线上事故：

• null必须用x === null判断，!x会把0、''、false全吃掉
• new String('a')是对象，typeof返回"object"，toString.call才返回"[object String]"，普通字符串字面量才是"[object String]"
• document.getElementById()可能返回null，element.addEventListener前必须先判空
• 从postMessage接收的数据，instanceof完全失效，只能靠toString.call或结构特征（如hasOwnProperty('timestamp')）识别