JS 中 typeof 和 instanceof 判断数组的常见陷阱

JavaScript 权威技术教程

在 JavaScript 日常开发中，准确判断一个未知变量是否为数组是最基础的高频需求之一。然而，许多初学者乃至具备一定经验的开发者，常常会误用 typeof 或 instanceof。核心结论是明确的：typeof [] 恒定返回 "object"，无法区分普通对象与数组；而 instanceof Array 虽然在单一全局上下文中能够正常工作，但在涉及 <iframe>、多窗口弹框（Window Popup）或微前端沙箱等跨执行上下文（Cross-Realm）场景中会直接判定失效。理解这背后的底层原因不仅能帮助我们规避线上 Bug，更是透彻掌握 JavaScript 类型系统与原型继承模型的关键一课。

一、typeof 判断数组的根本局限与底层原理

尝试使用 typeof 来判断数组是前端初学者最容易踩中的第一个误区。我们在控制台运行以下代码时，会发现无论传入什么数组，返回的结果均与预期相悖：

// 尝试使用 typeof 检验数组
console.log(typeof []);              // "object"
console.log(typeof [1, 2, 3]);       // "object"
console.log(typeof new Array());     // "object"

// 与普通对象及 null 对比
console.log(typeof {});             // "object"
console.log(typeof null);           // "object"

从代码输出可以看出，typeof [] 的求值结果是 "object"，它与普通字面量对象 {} 甚至 null 返回的结果完全相同。这使得 typeof 在语义上完全丧失了区分数组的能力。

1. 底层机制：为什么 typeof 会返回 "object"？

这一行为并非偶然设计失误，而是源自 JavaScript 诞生之初的底层数据存储结构。在早期 JavaScript 引擎的 C++ 源码实现中，变量的值以 32 位单元存储，由类型标签（Type Tag）和实际的数据内容指针（或直接数值）组合而成。

当时底层的低位类型标签规则规定：

• 000：表示引用对象（Object）。
• 1：表示 31 位整型（Int）。
• 010：表示双精度浮点数（Double）。
• 100：表示字符串（String）。
• 110：表示布尔值（Boolean）。

在 ECMAScript 规范定义中，数组并不是一种独立的原始数据类型（Primitive Type），而是一种具有特殊索引操作行为的“奇异对象”（Exotic Object）。它的底层类型标签就是 000。

typeof 操作符的设计初衷极其轻量，它只通过检查底层的这几位类型标签来直接返回预设的字符串映射。在遇到 000 时，它仅会进一步判断该对象内部是否包含可调用的 [[Call]] 内部方法（即判断是否为函数）。如果对象不可调用（如普通对象 {} 或数组 []），它就会统一且不加区分地返回 "object"。

二、instanceof 判断数组的原理与跨 Realm 隔离陷阱

既然 typeof 无法区分对象和数组，许多开发者自然会转向面向对象中的类型推导操作符：instanceof。在常规的单页面单窗口应用中，运行 [] instanceof Array 确实会返回预期的 true：

// 单窗口上下文环境下的检验
const list = ['Apple', 'Banana'];

console.log(list instanceof Array);   // true
console.log(list instanceof Object);  // true
console.log({} instanceof Array);     // false

这看起来非常完美，但在涉及多环境协作的复杂工程中，instanceof Array 隐藏着一个极其难以排查的“致命陷阱”：跨 Realm（跨执行环境上下文）的原型链失效。

1. instanceof 的实质工作机制

在深入探讨陷阱之前，必须清楚 A instanceof B 在底层到底做了什么。根据规范，表达式 A instanceof B 实际上是在沿着对象 A 的原型链（即通过内部指针 [[Prototype]] / __proto__ 不断向上攀爬），逐级比对是否存在一个节点的引用地址严格等于 B.prototype：

// 伪代码演示 instanceof 的底层遍历机制
function customInstanceof(left, right) {
  let proto = Object.getPrototypeOf(left);
  const prototype = right.prototype;

  while (proto !== null) {
    if (proto === prototype) {
      return true; // 找到了完全相同的原型对象引用
    }
    proto = Object.getPrototypeOf(proto);
  }
  return false;
}

请务必注意：比对使用的是引用地址同一性（===），而不是类名的字符串比对。

2. 致命陷阱：跨 Realm (iframe / Window / 沙箱) 隔离

在现代 Web 应用中，嵌入 <iframe>、使用 window.open() 弹出新窗口或在微前端框架的 JS 沙箱中运行代码是非常普遍的场景。在浏览器模型中，每一个 window 或 iframe 都对应着一个独立的执行环境（Realm）。

每一个 Realm 都拥有自己一套完全独立的全局对象体系、内置构造函数和内置原型：

• 主窗口拥有自己的 window.Array 及其原型对象（假设位于堆内存 0x00A1BC）。
• 子 iframe 拥有自己独立的 iframe.contentWindow.Array 及其原型对象（位于堆内存另一块独立地址 0x00F8E4）。

当我们把子 iframe 中生成的数组传递给父页面处理时，问题立刻暴露：

// 场景复现：父页面与子 iframe 通信
// 假设父页面动态创建了一个 iframe
const iframe = document.createElement('iframe');
document.body.appendChild(iframe);

// 从子 iframe 的上下文中创建一个原生数组
const iframeArray = iframe.contentWindow.Array(1, 2, 3);

// 1. 在子 iframe 上下文内部判断
console.log(iframeArray instanceof iframe.contentWindow.Array); // true

// 2. 传递给父窗口环境，使用父窗口的 Array 进行判断
console.log(iframeArray instanceof window.Array);              // false (❌ 陷阱触发！)

// 3. 检查其实际类型
console.log(Array.isArray(iframeArray));                       // true (依然是正经数组)

为什么 iframeArray instanceof Array 会返回 false？因为 iframeArray 的原型指向的是子环境的 iframe.contentWindow.Array.prototype（0x00F8E4）。当父窗口执行 instanceof Array 时，它沿着原型链一直在寻找父窗口的 window.Array.prototype（0x00A1BC）。由于两者在内存中是两个彼此隔离的独立对象，引用地址永不相等，原型链一直遍历到顶层的 null 也无法匹配，因此最终返回 false。

三、原型污染与 constructor 判断法的附加陷阱

部分开发者在意识到 typeof 失效后，尝试利用构造器属性 arr.constructor === Array 来检测数组：

const arr = [10, 20];
console.log(arr.constructor === Array); // true

然而，这种方法比 instanceof 更加脆弱，存在双重缺陷：

1. 同样存在跨 Realm 失效问题：子 iframe 的 iframeArray.constructor 指向的是子环境的 iframe.Array，与主窗口的 window.Array 同样不相等。
2. 极易被篡改和伪造：对象的 constructor 属性并不具备保护屏障，可以通过手动赋值或原型重写轻易覆写。此外，如果传入的值是 null 或 undefined，直接访问 .constructor 会抛出 TypeError: Cannot read properties of null/undefined 异常。

// constructor 轻易被篡改的示例
const fakeArr = { length: 2, 0: 'a', 1: 'b' };
fakeArr.constructor = Array; // 伪造构造函数
console.log(fakeArr.constructor === Array); // true (误判为数组！)

const realArr = [1, 2];
realArr.constructor = Object; // 手动重写构造函数
console.log(realArr.constructor === Array); // false (真数组被误判为 false！)

四、数组检测的正确解法与标准演进

为了彻底解决以上所有缺陷，ECMAScript 标准委员会和开源社区先后推行了两种稳健的检测途径：历史经典方案 Object.prototype.toString 与现代官方标准 Array.isArray()。

1. 经典解法：Object.prototype.toString.call

在 ECMAScript 5 正式标准化之前，jQuery、Underscore 等经典前端基础库普遍采用 Object.prototype.toString.call(val) 来进行高精度类型检测。

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

// 验证跨 Realm 表现
console.log(isArrayLegacy(iframeArray)); // true (完美穿透 iframe 隔离！)

为什么它有效？ 根据规范，当在任意目标对象上调用 Object.prototype.toString 时，JavaScript 引擎会提取该对象规范内部的 [[Class]] 内部属性（在 ES6+ 中由 Symbol.toStringTag 及内置内置槽共同决定）。对于数组对象，其内部类型永远标识为 "Array"，输出格式固定为 "[object Array]"。由于调用的是挂载在 Object.prototype 上的通用方法，它完全绕开了不同 Realm 构造函数引用地址不一致的问题。

2. 现代统一标准：Array.isArray()

从 ECMAScript 5.1（2011 年）起，官方正式引入了原生的 Array.isArray() 静态方法，专门用于终结数组判断的混乱局面。

// 现代开发统一标准写法
const normalArr = [1, 2, 3];
console.log(Array.isArray(normalArr));    // true
console.log(Array.isArray(iframeArray));  // true (原生安全穿透跨环境上下文！)
console.log(Array.isArray({}));           // false
console.log(Array.isArray(null));         // false

Array.isArray() 在底层是原生 C++ 实现的特权方法。当执行 Array.isArray(arg) 时，引擎在规范层直接执行 IsArray(argument) 操作：

• 如果 argument 是一个非对象（Primitive），直接返回 false。
• 如果 argument 包含数组内置奇异对象行为（具有特殊的 length 魔法属性管理机制），无论它来自于哪个 Window、iframe 还是 Worker 线程，均直接返回 true。
• 如果 argument 是一个 Proxy 代理对象，Array.isArray 会递归解包代理的目标对象，准确识别底层被代理的实体是否为数组。

3. 生产级 Polyfill 完整实现

虽然在当前所有活跃的 JavaScript 运行环境（Node.js、各大现代浏览器移动端与桌面端）中 Array.isArray 均已 100% 原生支持，但理解其 Polyfill 的编写规范依然是掌握工程健壮性的典范：

// 严谨标准的 Array.isArray Polyfill 范例
if (typeof Array.isArray !== 'function') {
  Array.isArray = function (arg) {
    // 严格过滤 null 和 undefined
    if (arg === null || typeof arg !== 'object') {
      return false;
    }
    // 利用内部 [[Class]] 标签安全判定
    return Object.prototype.toString.call(arg) === '[object Array]';
  };
}

五、全方案横向对比与技术选型建议

为了直观掌握不同方式在实际开发中的表现差异，我们将本文涉及的四种主要判断途径进行多维度特征横向对比：

检测方法	底层判定依据	普通对象与数组区分	跨 iframe / Realm 安全	抗篡改能力	推荐使用场景
typeof val	二进制类型标签 (000)	完全无法区分	无意义	高	仅用于检测基础原始类型和函数
val instanceof Array	原型链引用全等 (===)	单环境可区分	跨环境必失效	中（原型链可被修改）	仅适用于自定义类的继承关系比对
Object.prototype.toString.call(val)	内部 [[Class]] 槽标记	精准区分	天然安全	高（不受原型链断裂影响）	全类型检测通用工具库 / 极端降级
Array.isArray(val)	规范原生内置 IsArray 检查	精准区分	天然安全	最高（引擎内核保护）	日常开发与生产工程唯一首选

六、总结与核心行动清单

回顾整篇分析，我们可以将 JavaScript 判断数组的知识要点浓缩为以下三条清晰结论：

• 绝不用 typeof 判数组：底层 000 类型标签注定了它将数组、普通对象和 null 统统归类为 "object"。
• 慎用 instanceof Array：它依赖原型链上 Array.prototype 内存地址的恒等性，在跨 iframe、多窗口或微前端等复杂架构下必然产生误判。
• 坚定使用 Array.isArray()：作为 ECMAScript 官方钦定的原生方案，它性能卓越、语义精准，且能百分之百穿透 Realm 隔离，是现代 JavaScript 开发中判断数组的不二法则。