T

typeof null 返回 "object" 是历史遗留 bug，源于1995年Ja vaScript初版的实现错误，因向后兼容无法修复；检测 null 应使用 value === null。

先说个明确的结论：typeof 对 null 返回 "object"，这事儿从根儿上就是个 bug。不是设计意图，也不是什么“优雅的抽象”，纯粹是历史遗留问题，而且因为向后兼容的约束，永远没法修。

为什么 typeof null 是 "object"

问题出在 1995 年 Netscape 发布的第一版 Ja vaScript。当时 null 在底层被表示为全零的机器码，而引擎的类型判断逻辑恰好把全零当作对象指针来处理。于是 null 就这么阴差阳错地被打上了对象的标签。V8、SpiderMonkey 等所有主流引擎都沿用了这个实现，ECMAScript 标准后来也选择保留它——不是因为它合理，是因为改了它，成千上万的现存代码就会崩。

所以，别再说什么“typeof null 返回 object 是语言特性”了，它就是实打实的 bug，一个不允许修复的 bug。

检测 null 的正确方式是 value === null

如果依赖 typeof 来判断 null，几乎必然会翻车。唯一无歧义的方式就是严格相等：

if (value === null) { /* 处理 null */ }

现实中常见的误用有三种：

• !value：会把 0、""、false、undefined 全部误伤，因为它们在布尔语境下都是 falsy，不等于 null
• typeof value === "object"：不仅漏不掉 null，还把数组、正则、日期都一并当成检测对象，精准度极低
• value == null：虽然能同时匹配 null 和 undefined，但涉及隐式类型转换，语义模糊。如果逻辑上只关心 null，老老实实用 ===

需要同时区分 null 和 undefined？用 Object.is()

当 API 明确允许 null 但拒绝 undefined 时，=== 已经够用。但如果想封装一个健壮的工具函数，Object.is() 是更安全的选择：

function isNull(value) {
  return Object.is(value, null);
}

它对 null 的行为与 === 完全一致，但语义上更明确地表达了“值恒等”。有意思的是，Object.is() 还能正确处理 NaN 这类边界情况——当然，null 本身不涉及这个问题。

最后提醒一句：很多人写防御性代码时习惯先用 typeof 做分支判断，然后一不小心就在 null 上踩坑。只要记住一件事——null 是唯一一个 typeof 返回 "object" 却并非对象的值，其他所有对象（包括 Array、Date、RegExp）都符合直觉。记住这点，比背任何检测方法都管用。