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种核心判断方法各司其职，不能混用
没有“万能方法”，只有“场景适配”：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
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')）识别
