使用Object.prototype.toString.call精准检测JS数组

在 JavaScript 中，如果需要脱离运行环境限制、不受跨 iframe 隔离影响且免疫原型链篡改地检测一个值是否为数组，最底层且可靠的方案是执行 Object.prototype.toString.call(value) === '[object Array]'。该方法借由 Function.prototype.call 将目标值强制绑定到 Object 原型链顶端的 toString 方法上，直接触发 ECMAScript 规范定义的内部类型标签提取逻辑。本文将系统剖析该方法的规范运行机理、与其他常见检测手段的本质差异、工程化封装的最佳实践，以及在 ES6+ 新特性下的边界考量。

一、核心写法与即时验证

在不引入任何第三方库的情况下，直接调用以下表达式即可完成对目标值的严谨检测：

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

// 验证标准数组
console.log(isArray([1, 2, 3])); // true
console.log(isArray([]));        // true

// 验证容易引起混淆的类数组与特殊对象
console.log(isArray({ length: 0 }));             // false (普通纯对象)
console.log(isArray(document.querySelectorAll('div'))); // false (NodeList 类数组)
console.log(isArray(null));                       // false
console.log(isArray(undefined));                  // false

这一表达式的返回值恒为字符串 "[object Array]"。只要输入值底层是一个真实的 JS 数组，无论该数组来自当前 window 还是嵌入的子页面 iframe，比较结果都准确无误。

二、为什么常规检测手段会失灵？

在日常开发中，许多初学者往往会尝试使用 typeof、instanceof 或访问对象的 constructor 属性来判断数组。但在复杂或特定工程场景下，这三者均存在不可忽视的硬性缺陷。

1. typeof 运算符的历史包袱

在 JavaScript 语言的最初实现中，值在底层的机器码中是以类型标签存储的。对象类型的类型标签被指定为 0，而数组同样属于复合引用对象，其标签位也是 0。因此 typeof [] 的求值结果永远是 "object"，无法与普通的普通对象 {} 作区分。

2. instanceof 与跨 iframe (Realm) 困境

arr instanceof Array 的判定依赖于原型链追溯：它沿着 arr 的 __proto__ 向上检索，检查是否存在与右侧构造函数 Array.prototype 严格全等的引用。然而，浏览器中的每一个 <iframe>、弹窗页面（Popup）或微前端沙箱都拥有独立全局执行上下文（Realm）。各上下文之间维护独立的全局对象和构造函数：

// 模拟跨 iframe 场景
const iframe = document.createElement('iframe');
document.body.appendChild(iframe);
const iframeArray = iframe.contentWindow.Array;

const arrFromIframe = new iframeArray(1, 2, 3);

// 宿主环境的 Array 与 iframe 内部的 Array 是两个完全不同的内存对象
console.log(arrFromIframe instanceof Array); // false (失灵！)
console.log(arrFromIframe.constructor === Array); // false (失灵！)

// 使用 Object.prototype.toString.call 进行检测
console.log(Object.prototype.toString.call(arrFromIframe)); // "[object Array]" (仍然准确)

3. constructor 属性极易被篡改

通过检查 arr.constructor === Array 同样不可靠。不仅因为跨 iframe 存在构造器引用不一致问题，而且 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 (发生误判！)

三、底层运作机理：Object.prototype.toString 内部做了什么？

为什么直接对数组执行 [1, 2].toString() 得到的是 "1,2"，而借由 Object.prototype.toString.call([1, 2]) 就能获取到 "[object Array]"？这涉及原型链方法覆写机制与规范的内部求值流程。

1. 为什么必须使用 .call() 改变 this

当直接调用 arr.toString() 时，由于原型链上的查找顺序，引擎会首先在 Array.prototype 上找到已被数组重写过的 toString 方法。数组的重写版本专门用于将数组元素逐一转为字符串并用逗号拼接，实质相当于执行了 arr.join(',')。

只有通过 Object.prototype.toString.call(arr)，才能强制绕过 Array.prototype，直接调用保存在顶层 Object.prototype 上的原始 toString 实现，并将目标数组作为该方法运行时的 this 上下文传入。

2. ECMAScript 规范定义的执行算法

根据 ECMAScript 规范，当 Object.prototype.toString() 被调用时，引擎内部执行以下明确步骤：

1. 空值优先分支：若 this 为 undefined，直接返回 "[object Undefined]"；若 this 为 null，直接返回 "[object Null]"。该机制避免了直接访问属性带来的 TypeError。
2. 包装为对象：通过抽象操作 ToObject(this) 将参数转换为对象。
3. 读取内部类型槽（ES5 及以前）：读取对象的私有内置槽 [[Class]]。在规范中，真实数组的 [[Class]] 槽由引擎创建时永久标记为 "Array"，开发者无法通过用户态 JavaScript 脚本直接读取或修改该属性。
4. ES6+ 规范算法演进：引擎调用内部抽象判定 IsArray(O)，若为真且对象自身未定义 Symbol.toStringTag 属性，则标签名 tag 默认为 "Array"。
5. 拼接输出：将最终计算出的 tag 格式化为 "[object " + tag + "]" 字符串并返回。

四、主流数组判断方案横向对比

为了在不同架构和业务规模下做出明智的技术选型，我们将业内现存的几种核心检测方案进行全维度对比：

检测方式	同域普通数组	跨 iframe 数组	类数组对象	原型被修改	null / undefined
typeof val === 'object'	识别为 object	识别为 object	混淆为 object	混淆为 object	null 会误判为 object
val instanceof Array	准确识别	失效 (返回 false)	准确排除	可能误判	安全返回 false
val.constructor === Array	准确识别	失效 (返回 false)	可能被伪造	失效 (属性被改)	直接抛出 TypeError
Array.isArray(val)	精准识别	精准识别	准确排除	精准识别	安全返回 false
Object.prototype.toString.call(val)	精准识别	精准识别	准确排除并返回真身	精准识别	安全返回对应标签

五、工程化落地：封装高性能类型判断工具

在大型前端库、SDK 或基础框架的编写中，类型检测属于极其高频调用的代码段。如果直接在每次函数调用中都完整执行 Object.prototype.toString.call(v)，每一次都会发生两次原型链属性查找（从 Object 查找 prototype，再从原型查找 toString）。

最佳的工程实践是结合引用缓存与原生渐进增强策略：

// 1. 作用域顶层缓存方法引用，消除反复原型查找开销
const toString = Object.prototype.toString;

/**
 * 健壮的数组检测工具函数
 * @param {*} value 待检测的目标值
 * @returns {boolean} 是否为标准数组
 */
export const isArray = Array.isArray || function (value) {
  return toString.call(value) === '[object Array]';
};

/**
 * 通用精准类型提取器
 * @param {*} value 任意 JavaScript 值
 * @returns {string} 真实类型的标准字符串，如 'array', 'object', 'date', 'regexp'
 */
export function getRawType(value) {
  // 截取 "[object Xxx]" 中的 Xxx 部分并转换为小写
  return toString.call(value).slice(8, -1).toLowerCase();
}

六、ES6+ 时代的边界考量：Symbol.toStringTag 与 Proxy

随着 ECMAScript 2015 (ES6) 的普及，语言规范引入了 Symbol.toStringTag 这一内置元编程特性。开发者需要明确其对 Object.prototype.toString.call 的实际影响边界：

1. 自定义对象的 Symbol.toStringTag 无法伪装为数组

虽然开发者可以通过 Symbol.toStringTag 自定义返回标签，例如给普通对象伪造一个标签：

const fake = {
  [Symbol.toStringTag]: 'Array'
};

console.log(Object.prototype.toString.call(fake)); // "[object Array]"
console.log(Array.isArray(fake));                 // false

在 ES6+ 规范中，Array.isArray 底层依赖抽象操作 IsArray(O)，它直接验证对象的原生内部插槽（Internal Slot），任何用户态的 Symbol.toStringTag 均无法欺骗 Array.isArray。这是 Array.isArray 相比 Object.prototype.toString.call 在面对极端伪造对象时的独特防御优势。

2. Proxy 代理数组的透传特性

当数组被 new Proxy(target, handler) 包裹时，无论是 Array.isArray(proxyArr) 还是 Object.prototype.toString.call(proxyArr)，只要代理的底层目标（target）是数组且未拦截 getPrototypeOf 等陷阱，均能一致判定为真。这保障了现代响应式框架（如 Vue 3 的 reactive 数组）的正常运作。

七、总结与开发选型指南

在当下的 JavaScript / TypeScript 开发中，针对数组检测的核心原则可以明确归纳为两条简洁法则：

• 业务代码与现代项目：统一无脑选用 Array.isArray(val)。它是 ES5 即标准化的语言原生 API，在任何现代浏览器、Node.js 及跨 Realm 环境下均具备最佳的执行效率与安全性。
• 跨类型通用判断与基础库底层：如果不仅需要判断数组，还需要精准区分 Date、RegExp、Map、Set、Arguments 或在不支持 ES5 的超轻量微控制器嵌入环境中运行，Object.prototype.toString.call(val) 依然是整个 JavaScript 生态中最具通用性、生命力最为持久的基石方案。