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