typeof null返回"object"是因底层32位标签中null的二进制00被误判为对象，属无法修复的历史bug；ECMA标准为兼容性保留该行为，开发者应使用=== null或Object.prototype.toString.call()规避。
JavaScript中typeof null返回"object"，不是设计意图，而是一个低级但无法修复的bug。
底层内存表示导致误判
JavaScript最初由Brendan Eich在1995年十天内实现，底层采用C语言编写。当时所有值都用32位标签（tagged）表示，其中最低两位用于标识类型：
- 00 表示对象（object）——指针指向堆内存地址
- 01 表示整数（integer）
- 10 表示浮点数（double）
- 11 表示其他（如undefined、boolean、string等）
null被定义为“空指针”，在C中值为0x00000000。当解释器检查其类型标签时，最低两位是00，于是被错误归类为“对象”。这个判断逻辑简单粗暴，没单独为null设分支。
向后兼容性锁死修复可能
该行为在1996年发布的JavaScript 1.1中已固化，随后被写入ECMA-262标准（1997年第一版）。尽管ES6明确将null定义为原始类型（primitive），但typeof null === "object"必须保留，否则会破坏海量既有代码：
立即学习“Java免费学习笔记（深入）”；
- 大量条件判断依赖
typeof x === "object"来过滤非null对象，比如if (typeof obj === "object" && obj !== null) - 若改为
"null"，所有只检查"object"却未排除null的代码会突然失效 - TC39委员会评估后认为风险远大于收益，正式拒绝修正（参见ECMA issue #495）
现代开发中的应对方式
开发者应主动绕过这个陷阱，而不是依赖typeof判断null：
- 检测
null用严格相等：value === null - 区分对象与
null：可用value !== null && typeof value === "object" - 更健壮的对象检测（排除数组、null、Date等）：用
Object.prototype.toString.call(value) === "[object Object]" - TypeScript等类型系统会在编译期提醒
typeof null的歧义，鼓励显式处理
它是个历史包袱，不是特性。理解它源于底层实现的偶然性，而非语义合理性，就能避免踩坑。
