JS判断数组的三种方法对比：isArray、instanceof与toString

一、为什么不能使用 typeof 判断数组？

在 JavaScript 的类型系统中，变量分为基本数据类型与引用数据类型。对于除 Function 之外的所有引用数据类型（如 Array、Plain Object、Date、RegExp、Map、Set 等），使用 typeof 运算符检测时，其返回值均统一为 "object"：

const list = ['apple', 'banana'];
const obj = { name: 'apple' };

console.log(typeof list); // 输出: "object"
console.log(typeof obj);  // 输出: "object"
console.log(typeof null); // 输出: "object"

这一语言设计决定了 typeof 只能用来区分基本数据类型与引用类型，无法识别对象的具体细分类型。为了准确识别真数组并排除伪造的类数组对象（如 arguments、DOM 的 NodeList），ECMAScript 规范与工程实践形成了三种主要手段：Array.isArray()、instanceof Array 与 Object.prototype.toString.call()。

二、Array.isArray()：官方专设的标准首选

Array.isArray() 是 ECMAScript 5.1（2011年）正式引入的官方标准静态方法。它的设立初衷正是为了彻底终结此前社区在判断数组时面临的原型链缺陷与跨环境失效痛点。

1. 语法与基本使用

该方法接收单个参数并返回严格的布尔值 true 或 false：

// 标准真数组
Array.isArray([]);                   // true
Array.isArray(["1", "2"]);          // true
Array.isArray(new Array("a", "b"));  // true

// 类数组与普通对象（精准排除）
Array.isArray({ length: 0 });      // false (普通对象)
Array.isArray("abc");                // false (字符串)
Array.isArray(null);                 // false
Array.isArray(undefined);            // false

// 函数 arguments 与 DOM NodeList
(function() {
  console.log(Array.isArray(arguments)); // false (类数组非真数组)
})();

2. 规范底层实现与优势剖析

根据 ECMA-262 规范 7.2.2 章节关于 IsArray ( argument ) 抽象操作的定义，Array.isArray() 在执行时遵循以下逻辑：

• 若参数不是 Object，直接返回 false；
• 检查对象内部是否包含 Array 专属的底层内部插槽（Internal Slot）。在现代引擎中，数组对象在 V8 / JavaScriptCore 底层拥有专门的堆对象结构（如 JSArray 标记）；
• 若对象是 Proxy 代理对象，IsArray 会递归调用其目标目标对象（Target），穿透代理判断内部真实类型。

最关键的优势在于：它完全不依赖对象的原型链（Prototype Chain），也不比对任何全局对象的引用地址。哪怕该数组来自另一个独立的 iframe、另一个 window 上下文，或者原型链被手动修改，Array.isArray() 都能准确断言。

三、instanceof Array：原型链机制与致命软肋

在 Array.isArray() 推出前，很多开发者习惯使用 arr instanceof Array。虽然语法简短，但其底层运作机制带来了严重的局限性。

1. 运算原理

instanceof 是一个二元运算符，用于检测构造函数的 prototype 属性是否存在于待测对象的原型链上。执行 target instanceof Array 等价于调用规范抽象操作 OrdinaryHasInstance(Array, target)：

// 模拟 instanceof 的查找链路
function customInstanceof(left, right) {
  if (typeof left !== 'object' || left === null) return false;
  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）彻底失效

在浏览器环境中，每个 <iframe>、弹窗窗口（window.open）甚至 Web Worker 都拥有一个全新的独立执行环境（即 ECMAScript 中的 Realm）。每个 Realm 都有各自独立的全局对象和内置构造函数副本。

这意味着：主窗口的 window.Array.prototype 与子窗口的 iframe.contentWindow.Array.prototype 位于完全不同的堆内存地址，两者引用严格不相等：

// 跨 Realm 失效示例
const iframe = document.createElement('iframe');
document.body.appendChild(iframe);

// 从 iframe 中创建一个原生数组
const iframeArr = iframe.contentWindow.Array(1, 2, 3);

// 1. instanceof 误判 (返回 false，发生假阴性)
console.log(iframeArr instanceof Array); // false (致命缺陷！)

// 2. Array.isArray 稳健识别 (返回 true)
console.log(Array.isArray(iframeArr));    // true (完全正常)

3. 致命问题二：原型链篡改导致误判

由于 instanceof 仅检查原型链指针，一旦普通对象的人工原型被指向 Array.prototype，就会产生严重假阳性误判：

const fakeArray = {};
Object.setPrototypeOf(fakeArray, Array.prototype);

console.log(fakeArray instanceof Array); // true (严重误判！并非真实数组)
console.log(Array.isArray(fakeArray));    // false (正确识别，排除伪造对象)

四、Object.prototype.toString.call()：经典稳健的反射机制

在没有 Array.isArray() 的 ES3 时代，前端社区最为信赖的万能类型检测方法是借用 Object.prototype.toString。

1. 为什么不能直接调用 arr.toString()？

在 JavaScript 原型继承模型中，Array.prototype 自身重写了从 Object.prototype 继承而来的 toString() 方法。当对一个数组直接执行 arr.toString() 时，实际调用的是数组特化的版本，其效果等同于 arr.join(',')：

const arr = [1, 2, 3];
console.log(arr.toString()); // 输出: "1,2,3" (无法获取类型标签)

因此，必须通过 Function.prototype.call，将执行上下文 this 绑定为待测对象，强制调用顶层原始的 Object.prototype.toString。

2. 内部标签提取机制

ECMA-262 规范 19.1.3.6 详细定义了 Object.prototype.toString() 的执行步骤：

• 如果 this 值为 undefined，返回 "[object Undefined]"；
• 如果 this 值为 null，返回 "[object Null]"；
• 将 this 转换为对象；
• 判断对象是否具备原生 Array 内部槽位（或 ES3/5 的内部 [[Class]] 属性为 "Array"）；
• 拼接输出字符串："[object " + tag + "]"，对于原生数组固定输出 "[object Array]"。

3. 兼容性与 Polyfill 实现

该机制能够完全穿透跨 Realm 隔离，且能够抵御简单的原型链篡改（fakeArray 的内部 [[Class]] 仍为 "Object"，返回 "[object Object]"）。在编写向下兼容至 IE6-IE8 的基础类库时，官方标准推荐的 Polyfill 便是基于该方法构建：

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

五、数组判定工程决策流与推导步骤

在理解了三种方法的底层原理后，我们可以构建一套完整的数组判定工程推导流程。它清晰展示了从变量输入到类型确权的完整判定分支：

执行该决策流程时，具体步骤分为四个阶段：

1. 阶段一：基础非空防护（Guard Phase）： 首先执行 typeof target === 'object' && target !== null。对于所有原始数据类型（数字、字符串、布尔、Symbol、BigInt、undefined）以及 null，立即判定为 false，快速短路。
2. 阶段二：标准环境检测（Capability Phase）： 检测当前运行时是否包含原生的 Array.isArray 方法。在当今所有的现代浏览器（Chrome、Edge、Safari、Firefox）及 Node.js / Deno / Bun 环境中，该条件恒为 true。
3. 阶段三：执行内建高效确权（Verification Phase）： 直接调用 Array.isArray(target)。V8 引擎会直接通过内部槽位完成 O(1) 级的即时判定，无需回溯原型链，无字符串构造开销。
4. 阶段四：古老宿主降级分支（Fallback Phase）： 若运行在受限的嵌入式古老 JS 引擎（如极早期客户端或老式自动化测试套件），降级调用 Object.prototype.toString.call(target) === '[object Array]'，保障跨环境与防篡改准确性。

六、三种方法的横向对比与全维度总结

为了直观对比三种方法在技术指标上的差异，以下整理了多维对比矩阵：

七、工程实践场景与总结建议

在日常开发与架构设计中，面对不同的应用场景，推荐采取以下落地规范：

• 业务开发（99% 的场景）： 在 React、Vue、Node.js 服务端以及前后端数据交互中，统一且唯一使用 Array.isArray(val)。代码清晰易读，性能最佳，并享有 TypeScript 原生支持的类型自动收窄（Type Guard）特性。
• 底层工具库与通用类型提取： 当需要构建一个包含 isNumber、isString、isFunction、isDate、isArray 的通用类型探测库（如类似 Lodash 的 getType(val) 工具函数）时，使用 Object.prototype.toString.call(val) 能够一套逻辑覆盖所有内置引用类型。
• 重构与代码规范审查： 全面排查项目中存量的 arr instanceof Array。如果业务中存在微前端沙箱、iframe 嵌入或者跨窗口通信，务必立即替换为 Array.isArray()，防止引发潜伏的生产故障。