typeof null返回"object"是因底层32位类型标签中null全零值（000）与object标签冲突所致，该历史bug自1996年固化并被ecma规范强制保留为兼容性例外。
JavaScript 中 null 被 typeof 识别为 "object"，不是类型判断逻辑出错，而是底层二进制标签机制与历史兼容性共同锁定的结果。它不影响运行，但会干扰类型守卫和条件分支，尤其在对象判空、API 兼容检测等场景中容易引发静默错误。
为什么 typeof null === "object" 是个“稳态错误”
1995 年 JS 初版用 32 位字存储值，低两位作类型标记：00 表示对象指针；null 定义为空指针，机器码全零（0x00000000），低两位自然也是 00。解释器未单独设分支，直接归入 object 分支。
该行为从 JavaScript 1.1（1996）起固化，ECMA-262 第一版（1997）将其写入规范。尽管 ES6 明确将 null 归为原始类型，但规范附录强制要求 typeof null 必须返回 "object"——这是“必须保留的兼容性例外”。
- TC39 曾评估修复提案（ECMA issue #495），结论是风险远超收益
- 全球海量代码依赖
typeof x === "object"做粗筛，再配合&& x !== null排除 - 哪怕只在严格模式下变更，也会导致条件跳过、类型守卫失效、监控埋点异常等连锁问题
实际开发中常见的误判场景
仅靠 typeof 判断对象类型，在以下情况极易出错：
-
访问属性前未排除 null：如
if (typeof obj === "object") { obj.name }，当obj为null时会抛Cannot read properties of null -
浏览器 API 兼容检测失准：例如
typeof localStorage === "object"成立，但若页面禁用 localStorage，其值可能为null或不可用对象，需额外验证localStorage.setItem是否为函数 -
序列化或 ORM 映射漏判：后端返回
{"user": null}，前端用typeof data.user === "object"误认为可展开，导致字段提取失败
安全可靠的类型检测组合方案
避免单点依赖 typeof，应分层校验：
-
检测 null：始终用
value === null（不能用== null，会连undefined一起匹配） -
确认非 null 对象：组合判断
value !== null && typeof value === "object" -
区分普通对象与其他引用类型：用
Object.prototype.toString.call(value) === "[object Object]"，它能准确区分数组、日期、正则、null、undefined 等 -
构造函数级检测（如需）：对
Promise、IntersectionObserver等 API，先查typeof，再尝试最小实例化或检查原型方法，例如：typeof Promise === "function" && typeof Promise.prototype.then === "function"
现代工具链如何缓解这一问题
TypeScript 和主流 Lint 工具已将该行为纳入类型系统设计：
- TypeScript 的
strictNullChecks开启后，null和undefined是独立类型，typeof类型推导不参与运行时判断，编译期即提示潜在空访问 - ESLint 规则如
no-implicit-coercion、no-unused-expressions配合自定义插件，可捕获typeof x === "object"后直接使用x.xxx的风险模式 - 运行时断言库（如
ts-runtime、zod）在解构响应数据时，默认对null做显式拒绝，而非依赖typeof过滤
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
