JavaScript类型判断：从入门到架构设计全面实战攻略

JavaScript 的类型判断看似基础，实则暗藏诸多玄机。它并非简单的语法糖，而是整个运行时逻辑的根基。一旦写错 typeof 或误用 instanceof，轻则导致参数校验失效，重则引发跨 iframe 通信崩溃、API 解析出错。真正可靠的类型判断，必须精准匹配数据的本质——是值类型还是引用类型？由哪个构造器生成？在哪个执行上下文中？

要想从根源上理清类型判断，第一步就是明确区分原始类型与引用类型——这决定了后续所有判断方法是否有效。

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

JavaScript 只有两大类本质：原始类型（栈中直接存储值）和引用类型（栈中存储内存地址）。这一区别直接决定了后续方法能否发挥作用：

• 原始类型共 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 会带来巨大的维护风险。应当统一收口，核心做法包括：

• 定义 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')）来识别