typeof null 返回 "object" 是因早期32位标签机制中null的全零内存值被误判为对象指针，后因兼容性锁死无法修正，成为必须保留的历史行为。
JavaScript 中 typeof null 返回 "object" 不是兼容性“适配”，而是兼容性“锁死”——它本是一个底层实现的偶然结果，却因海量既有代码依赖而被迫永久保留。
null 在 typeof 中被识别为 object 的根源
1995 年 Brendan Eich 用十天实现 JavaScript 原型时，采用 32 位标签（tagged value）机制表示值类型。其中最低两位（或三位）用于标记类型：
-
00（或000）表示对象指针 —— 指向堆内存的有效地址 -
null在 C 层被实现为空指针，内存值为全零（0x00000000），其低位自然匹配对象标签 - 引擎未单独为
null设置分支判断，直接按标签归类，于是typeof null得出"object"
为何无法修正：兼容性成为硬约束
该行为从 Netscape Navigator 2.0（1996）起固化，1997 年写入 ECMA-262 第一版标准。此后任何修改都会破坏大量现实代码：
- 许多库用
typeof x === "object"粗筛引用类型，再显式排除null（如&& x !== null） - 若改为返回
"null"，所有漏掉null检查的条件逻辑将意外放行，引发Cannot read property of null - TC39 明确拒绝修复（见 ECMA issue #495），ES 规范将其列为必须保留的“历史行为”（ES2024 §12.5.5.1）
现代开发中绕过该限制的实际做法
不依赖 typeof 单独判断 null，而是组合使用更精确的检测手段：
立即学习“Java免费学习笔记（深入）”；
- 判空用严格相等：
value === null（语义清晰、性能最优） - 区分普通对象与
null/Array/Date等：Object.prototype.toString.call(value) === "[object Object]" - 在 TypeScript 中，
null是独立类型，编译器会主动提示未处理的null分支，从源头规避运行时风险
它不是兼容性设计，而是兼容性代价
这个结果没有服务于某种抽象一致性，也没有提升类型系统表达力。它只是 JavaScript 在速度优先、时间紧迫、生态爆炸式增长的现实下，留下的一个可感知的“指纹”。理解它，不是为了接受反直觉，而是为了避开那些看似安全、实则脆弱的类型假设。
