为什么typeof不能直接判断JS数组类型

在 JavaScript 中直接对数组执行 typeof []，得到的结果并不是直观预期的 "array"，而是 "object"。这是因为数组在 JavaScript 底层被设计为一种继承自顶层对象原型的特殊对象（异质对象），且语言运行时的底层类型标签将所有非函数类的引用数据结构统一归类为对象。本文将从底层类型标签、规范约束、原型继承和执行环境四个维度，深入解析这一现象的具体成因，并提供生产环境中最稳健的数组鉴别方案。

一、直观表现：typeof 的分类局限

typeof 是 JavaScript 提供的用于检测变量原始类型的基本运算符。在日常开发中，我们常常使用它来辨析字符串、数字、布尔值或函数：

typeof "hello";        // "string"
typeof 1024;           // "number"
typeof true;           // "boolean"
typeof function() {};  // "function"

然而一旦将目标换成复杂数据类型，typeof 的细分能力就会迅速失效：

typeof {};             // "object"
typeof [1, 2, 3];      // "object"
typeof new Date();     // "object"
typeof /abc/g;         // "object"
typeof new Set();      // "object"

无论传入的是纯粹的对象字面量、索引数组、日期实例还是集合，typeof 返回的结果无一例外全是 "object"。这就决定了 typeof 只能告诉开发者“该值属于引用对象族群”，而根本无法指明它究竟是不是一个真正的数组。

二、底层机理：早期的 32 位单元与类型标签

要理解这种行为，必须追溯到 1995 年 JavaScript 第一版引擎（SpiderMonkey）的底层内存表示方式。

在最初的实现中，JavaScript 运行时使用 32 位机器字来表示变量的值。为了在不引入过大内存开销的前提下区分变量类型，引擎将这 32 位拆分为两个部分：高位存储实际数据内容或堆内存引用指针，而最低的 1 到 3 位被用作“类型标签（Type Tag）”。

当时设定的类型标签映射规则如下：

• 000：表示引用对象（Object），高位存储指向堆内存中对象结构的指针。
• 1：表示 31 位带符号整数（Int）。
• 010：表示双精度浮点数（Double）的指针。
• 100：表示字符串（String）的指针。
• 110：表示布尔值（Boolean）。

typeof 运算符在设计之初，其定位就是一个轻量、快速的操作符。它的实现机制非常直接：只读取变量前 3 位的类型标签。如果是 000，就直接返回字符串 "object"（只有当该对象同时挂载了可调用的函数内部方法时，才特殊返回 "function"）。

数组在内存中也是作为复合结构在堆中开辟空间的，它持有的指针低三位同样是 000。typeof 根本不会进一步探查这片堆内存里存放的是键值映射还是数组元素，因此返回 "object" 是底层实现机制决定的必然结果。（注：著名的 typeof null === "object" 也是这一机制的副产物，因为空指针的 32 位全为 0，低位同样命中了 000）。

三、规范定义：数组在 ECMAScript 中的本质是对象

从 ECMAScript 规范体系来看，数组从来不是一种与“对象”平级的基础语言类型，而是对象的特殊衍生形态。

在规范定义中，标准内置类型只有 Undefined、Null、Boolean、Number、BigInt、String、Symbol 和 Object。数组属于 Object 家族中的“异质对象”（Exotic Object）。

数组与普通对象相比，唯一的特殊之处在于引擎为其实现了一套特殊的内部方法与行为：

1. 属性名规则：数组的索引实际上是被转化为字符串的非负整数属性名（例如 arr[0] 访问的实际上是属性 "0"）。
2. 自动联动的 length 属性：向数组添加新数字索引属性或直接修改 length 时，引擎内部会自动同步截断或扩充元素。
3. 原型链继承：数组实例的原型是 Array.prototype，而 Array.prototype 的上一层原型正是 Object.prototype。

ECMAScript 规范在 typeof 运算符求值规范表中明确写明：对于没有实现 [[Call]] 内部方法的任何对象，计算结果一律为 "object"。数组并未实现 [[Call]]，因而在语法规范层面也被确定返回 "object"。

四、避坑指南：为什么 instanceof Array 仍不够可靠？

意识到 typeof 的缺陷后，许多开发者会转向 instanceof 操作符：

const list = [1, 2, 3];
console.log(list instanceof Array); // true

这在单一全局上下文的应用中通常能正常工作，但它存在一个严重的隐患：无法跨全局执行环境（Realm）正常检测。

在前端应用中，如果页面包含了 <iframe>，或者在 Node.js 中使用了 vm 沙箱，就会产生多个相互独立的全局作用域（Global Realm）。每个 Realm 都会初始化自己独立的一套内置对象副本：

• 主窗口拥有属于自己的 window.Array 和 window.Array.prototype；
• 子 iframe 拥有完全独立的 iframe.contentWindow.Array 和 iframe.contentWindow.Array.prototype。

instanceof 的工作原理是检查构造函数的 prototype 是否存在于目标对象的原型链上。当子页面向父页面传递一个数组时：

// 假设从子 iframe 获取了一个数组 subArray
subArray instanceof window.Array; // 结果为 false！

因为 subArray 的原型是 iframe.contentWindow.Array.prototype，它与父窗口的 window.Array.prototype 在内存中是完全隔离的两个引用。此时 instanceof 便会误报，判断失效。

五、正解方案：如何精准判断一个变量是数组？

针对上述痛点，现代 JavaScript 与经典规范提供了两种坚固无误的判断方法。

方法 1：Array.isArray()（现代规范首选推荐）

ECMAScript 5 正式引入了 Array.isArray() 原生静态方法。它是目前最干净、最具语义且天然免疫跨 Realm 问题的标准方案：

Array.isArray([]);                // true
Array.isArray([1, 2, 3]);         // true
Array.isArray(new Array());       // true

// 排除其他对象与类数组
Array.isArray({});               // false
Array.isArray(null);             // false
Array.isArray({ length: 2 });    // false（类数组对象不是真实数组）

方法 2：Object.prototype.toString.call()（经典防御式通用方案）

在不支持 ES5 的极老旧环境或通用底层库中，借用顶层对象的 toString 方法是行业公认的黄金标准：

function isArray(val) {
  return Object.prototype.toString.call(val) === '[object Array]';
}

console.log(isArray([])); // true
console.log(isArray({})); // false

此方法的底层依据是 ECMAScript 规范中对 Object.prototype.toString() 的规定：当执行该方法时，引擎会读取传入对象的内部标识 [[Class]]（在现代规范中由 @@toStringTag 配合默认规则解析），对于数组实例固定返回 "[object Array]"。该标识同样具备跨全局环境不变性。

六、技术方案对比与决策路径

在面对不同类型的数组检测需求时，可依照以下判定矩阵与决策路径选择最合理的技术实现：

Array.isArray(document.querySelectorAll('div')); // false
Array.isArray(arguments);                          // false

七、总结

typeof [] 返回 "object" 并不是一个需要修复的临时错误，而是 JavaScript 自诞生以来的底层架构设计与规范演进共同作用的必然表现：

• 底层上，早期的 32 位机器字采用低位 000 作为对象类型标签，数组作为堆内存复合结构共用了这一标签；
• 规范上，数组本质上是继承自 Object.prototype 的异质对象，未实现 [[Call]] 方法的对象在 typeof 运算中统一输出 "object"；
• 实践中，instanceof Array 受制于多全局环境（iframe）的原型隔离问题；开发中应当优先使用现代标准的 Array.isArray()，或者在基础库中使用 Object.prototype.toString.call() 作为稳健兜底。