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