JS判断是否为数组：为什么typeof不准确

掌握 JS 类型系统底层的 Type Tag 设计、多 Realm 执行栈陷阱与标准数组判定实践

一、情境引入：一次常见的数组类型判断失误

假设我们正在开发一个数据展示模块，前端需要接收后端返回的用户列表并执行渲染。为保证程序健壮性，通常需要在调用 list.map(...) 之前对变量做有效性检验：

// 假设服务端返回了不符合预期的数据结构
function renderUserList(list) {
  // 初学者常犯的校验误区：认为数组也是 object，只要检查是不是 object 即可
  if (typeof list === 'object') {
    // 当 list 为普通对象 {} 时，此条件依然成立！
    // 下面这行代码会立刻抛出：Uncaught TypeError: list.map is not a function
    return list.map(user => user.name);
  }
}

如果开发者尝试写 typeof list === 'array'，控制台将显示该表达式的值永远是 false。在现代 JavaScript 中，无论是空数组 []、含有元素的高维数组还是 typed array，typeof 计算出来的结果无一例外都是字符串 "object"。

二、深入底层：为什么 typeof [] 会返回 "object"？

要理解这个现象，必须回溯到 JavaScript 诞生之初的底层数据存储模型。

1. 32 位机器字与 Type Tag（类型标签）机制

在早期的 JavaScript 引擎（如 Netscape 的 SpiderMonkey 最初实现）中，出于执行效率与内存紧凑性的考虑，变量的值在底层通过一个 32 位的机器字来表示。这个 32 位的字被划分为两部分：

• 高位部分（第 31 位至第 3 位）：存储实际数据的堆内存指针或数值内容；
• 低位部分（最低 1 到 3 位）：专门用来充当类型标签（Type Tag），用来标记这个变量所指向的数据类型。

如上图所示，当低 3 位的值为 000 时，引擎判定该变量指向一个堆内存中的对象引用（Object）。typeof 操作符在设计时的底层逻辑非常简单：它仅仅检查传入变量在当前机器字中的低位 Tag 标识，并据此直接映射为一个预定义的字符串。

由于 JavaScript 中的数组从语言本质上并不是独立于对象的底层基元，而是建立在对象体系之上的特殊对象，因此它的引用指针低位同样携带 000 标签。typeof 并不会深入遍历其原型链去确认构造函数，因此立即返回 "object"。

2. 数组在规范中的本质：带有 length 魔法的 Exotic Object

在 ECMAScript 规范定义中，Array 属于外来对象/异质对象（Exotic Object）。它与常规对象（Ordinary Object）唯一的实质区别在于其拥有定制化的内部方法 [[DefineOwnProperty]]：

• 当设置数字索引属性时，内部会自动计算并同步更新 length 属性；
• 当主动缩减 length 属性数值时，索引大于等于新长度的属性会被自动删除。

除了这层与 length 绑定的内部行为外，数组在内存结构、属性寻址和原型继承方面与普通对象完全一致。对于仅观察表面 Tag 的 typeof 而言，完全无法感知这些内部行为的差异。

三、常见替代方式的局限与潜在陷阱

既然 typeof 无法区分数组，很多开发者会尝试使用 instanceof 或 constructor 属性。然而在特定工程场景下，这两种方法同样存在明显的缺陷。

1. 为什么 arr instanceof Array 在跨 iframe 场景下会失效？

instanceof 操作符的工作原理是检查右侧构造函数的 prototype 对象是否存在于左侧变量的原型链上。在单一全局页面环境下，[] instanceof Array 确实返回 true，看似完美。

但在现代 Web 应用中，微前端架构、嵌套 iframe 或多 Window 交互十分普遍。每一个全局窗口都拥有独立的 JavaScript 执行环境（Realm），即拥有各自独立的全局对象和内置构造函数原型：

// 创建一个子 iframe 环境
const iframe = document.createElement('iframe');
document.body.appendChild(iframe);

// 在 iframe 内部创建一个数组
const iframeArray = iframe.contentWindow.Array(1, 2, 3);

// 在父窗口中检测：
console.log(iframeArray instanceof Array); 
// 运行结果：false！❌

当跨窗口传递数据时，iframeArray 的内部原型链指向的是子窗口的 iframe.contentWindow.Array.prototype（内存地址如 0x00B2），而父窗口的 instanceof Array 正在比对父窗口的 window.Array.prototype（内存地址如 0x00A1）。两者物理地址不同，导致 instanceof 判定失败。

2. arr.constructor === Array 的双重缺陷

检查实例对象的构造函数存在更严重的可靠性问题：

• 容易被意外篡改：对象的 constructor 属性是可写的，一旦业务代码或原型扩展重写了它，判断立刻失真；
• 空值安全隐患：如果待判断变量为 null 或 undefined，访问 .constructor 会直接引发 TypeError: Cannot read properties of null 导致系统崩溃；
• 同样受限于多 Realm：子窗口数组的 constructor 指向子窗口的 Array 构造函数，跨环境比对依然不相等。

四、可靠判断数组的标准解法

针对以上问题，JavaScript 语言委员会与工程实践给出了真正具备跨环境防御能力的严谨解决方案。

1. 首选方案：ES5 标准方法 Array.isArray()

从 ECMAScript 5.1（2011年）开始，规范正式引入了 Array.isArray() 原生静态方法。这是目前官方最推崇、性能最高、最具语义的判定方式：

const list = [1, 2, 3];

Array.isArray(list);        // true
Array.isArray({});          // false
Array.isArray(null);        // false
Array.isArray("string");    // false

// 即使在跨 iframe 场景下：
Array.isArray(iframeArray); // true！原生免疫 Realm 隔离

底层原理：Array.isArray 不依赖于原型链地址的比对。在 V8 等引擎底层，它直接通过 C++ 层检查对象内部的隐式字段 [[Class]] 是否为 "Array"，或者检查对象是否为 Array Exotic Object。因此无论数组来自哪个窗口，都能得到 100% 准确的结果。

2. 经典兜底方案：Object.prototype.toString.call()

在需要兼容极老旧运行环境（如 IE8 及更早版本），或者构建底层运行时基础设施库时，可以使用基于内部标签抽取的经典方法：

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

console.log(isRealArray([1, 2])); // true
console.log(isRealArray({}));     // false

原理解析：调用 Object.prototype.toString 时，规范规定引擎会提取该对象内部的 [[Class]] 属性（在 ES6 之后结合 Symbol.toStringTag）。对于数组实例，规范规定其内置标签必须为 "Array"，拼接后得到 "[object Array]"。该方法同样脱离原型链地址限制，具备全局统一性。

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

五、类数组对象（Array-like）的甄别与防坑指南

在日常开发中，还有一类特殊的结构极易引发误解，即类数组对象。例如函数的 arguments 对象、DOM 遍历返回的 NodeList / HTMLCollection，以及 Uint8Array 等类型化数组。

function checkArgs() {
  console.log(Array.isArray(arguments)); 
  // 输出：false！arguments 拥有 length 和数字键，但不是真正数组
}
checkArgs(1, 2);

const nodes = document.querySelectorAll('div');
console.log(Array.isArray(nodes)); 
// 输出：false！NodeList 属于类数组

如何应对类数组：如果你的函数设计需要同时兼容真数组与类数组对象，不应该使用 Array.isArray 直接粗暴拦截，而应该结合转换策略：

• 统一转换为真数组：使用 Array.from(likeArray) 或扩展运算符 [...likeArray]（需具备迭代器协议）；
• duck typing 鸭子类型检测：检测对象是否非空，且具备数值类型的 length 属性。

六、全方案综合对比与选型建议

为了帮助大家在日常编码中快速决断，下表汇总了 JavaScript 中常见类型检测手段在面对数组时的实际表现：