IE8 等旧浏览器中 JS 数组类型检测的 Polyfill 实现

在 ECMAScript 5 (ES5) 规范之前，JavaScript 缺乏官方标准的数组判定方法，而旧版浏览器（如 IE8 及更早版本）仅支持 ES3 标准，原生并不存在 Array.isArray API。面对 typeof 无法区分普通对象与数组、instanceof 在多窗口（iframe）嵌套环境中失效等棘手问题，最健壮且符合规范的解决途径是利用 Object.prototype.toString.call(arg) === '[object Array]' 实现兼容补丁（Polyfill）。本文将完整拆解其失效根源、规范原理并提供标准生产级实现。

一、为什么原生 Array.isArray 在 IE8 中缺失？

ECMAScript 语言规范在经历长期停滞后，于 2009 年 12 月正式发布了 ECMAScript 5 (ES5)。该版本正式将 Array.isArray() 引入为全局 Array 构造函数的静态方法，用于准确鉴别一个值是否为原生数组。

微软的 Internet Explorer 8 (IE8) 发布于 2009 年初，其内置的 JScript 引擎主要遵循 ECMAScript 3 (ES3) 规范，并未内置 ES5 新增的原生静态方法。当在 IE8 及其更低版本浏览器中直接调用 Array.isArray([1, 2, 3]) 时，引擎会直接抛出著名的脚本错误：

// 在 IE8 环境中直接调用报错示例
Array.isArray([1, 2, 3]); 
// SCRIPT438: 对象不支持“isArray”属性或方法 (Object doesn't support property or method 'isArray')

为了保证在包括 IE8 在内的旧宿主环境中平稳运行依赖 Array.isArray 的代码库，开发者必须在执行任何业务逻辑之前为其注入功能完备的 Polyfill。

二、常见旧式检测方案的缺陷与失效场景

在 Array.isArray 标准化之前，社区曾尝试过多种数组识别方案。然而，这些方式在遇到复杂运行场景或边界输入时均存在不同程度的缺陷。

1. typeof 运算符的局限

typeof 是 JavaScript 语言最基础的类型检查工具，但对于对象类型的区分度极低。在规范中，数组本质上是一个具有特殊数字索引和长度行为的对象，因此 typeof [] 的返回值为 'object'。

typeof [];          // 返回 'object'
typeof {};          // 同样返回 'object'
typeof null;        // 甚至 null 也返回 'object'

显而易见，typeof 无法区分普通对象、数组以及 null，因此完全无法胜任数组判断。

2. instanceof 运算符在跨窗口（Iframe）下的致命缺陷

arr instanceof Array 曾长期作为判断数组的主要手段。它的工作原理是回溯 arr 的原型链，检查 Array.prototype 是否出现在其原型链上。

在单一执行上下文（单个网页窗口）中，这种方式表现良好；但当页面引入 <iframe>、弹窗窗口（window.open）或跨框架通信时，instanceof 会彻底崩溃。

3. constructor 属性的不可靠性

通过 arr.constructor === Array 判定同样存在双重缺陷：一方面，与 instanceof 相同，它依赖当前窗口的 Array 引用，跨窗口同样失败；另一方面，对象的 constructor 属性是可读写的，甚至可以被原型重写破坏；若传入 null 或 undefined，访问属性还会导致程序直接中断。

三、深入解析：跨窗口（Iframe）环境为何导致 instanceof 判定失效

要真正理解为什么旧环境中的数组检测如此棘手，必须深入浏览器的执行上下文（Execution Context）隔离机制。

在浏览器中，主窗口与每一个嵌入的 <iframe> 拥有各自完全独立的全局执行上下文与作用域堆栈。这意味着每个窗口在初始化时都会各自实例化一套独立的内置构造函数与原型链：

• 父窗口拥有自己的 window.Array 与 window.Array.prototype。
• 子窗口（iframe）也拥有属于它自己的 iframeWindow.Array 与 iframeWindow.Array.prototype。

这两个 Array 构造函数虽然名称相同，但它们在浏览器物理内存中是两个截然不同的对象引用（即 window.Array !== iframeWindow.Array）。

// 假设从页面中创建的子 iframe 中获取数组
var iframe = document.createElement('iframe');
document.body.appendChild(iframe);
var iframeArray = iframe.contentWindow.Array;
var testArr = new iframeArray(1, 2, 3);

// 在父页面中进行 instanceof 检测：
console.log(testArr instanceof Array); 
// 输出：false！因为 testArr 的原型链上是 iframeWindow.Array.prototype，而不是当前宿主的 Array.prototype

当一个来自子 iframe 的数组被传递到父窗口或第三方组件库中时，所有基于 instanceof Array 或 constructor === Array 的代码都会错误地将其识别为“非数组”，从而引发难以排查的数据处理异常。

四、标准解法：基于 [[Class]] 内部属性的终极方案

为了解决上述所有缺陷，ECMAScript 规范设计者为每个原生对象赋予了一个内部属性 [[Class]]。这个属性由引擎在对象创建时内部指定，标明其真实类别，外部脚本既无法直接访问，也无法恶意重写。

根据 ECMAScript 3 / ES5 规范第 15.2.4.2 节对 Object.prototype.toString() 的定义，当调用该方法时，引擎会执行如下算法步骤：

1. 获取当前调用上下文（this 对象）。
2. 读取 this 对象的内部属性 [[Class]] 的值。
3. 拼接字符串，返回由 "[object "、[[Class]] 的值以及 "]" 组成的字符串。

对于由任何窗口、任何环境构造的原生数组实例，其内部 [[Class]] 属性的值恒为字符串 "Array"。

五、IE8 Array.isArray Polyfill 的标准实现与工程落地

掌握了底层原理后，我们可以构建一个完全符合规范且具备极高稳定性的 Array.isArray Polyfill。

1. 完整代码实现

/**
 * Array.isArray Polyfill for IE8 and legacy ES3 environments
 * Specification: ECMAScript 5.1 (ECMA-262) Section 15.4.3.2
 */
(function() {
  // 1. 特性检测守卫：若引擎已原生支持则绝不重写
  if (!Array.isArray) {
    // 2. 提前缓存原型链查找引用，优化高频调用性能
    var nativeToString = Object.prototype.toString;

    // 3. 挂载标准静态方法
    Array.isArray = function(arg) {
      // 4. 强制以 arg 作为 this 调用 Object.prototype.toString
      return nativeToString.call(arg) === '[object Array]';
    };
  }
})();

2. 实现中的三个关键工程考量

• 特性检测守卫（Feature Detection Guard）：始终在赋值前判断 if (!Array.isArray)。现代浏览器中的原生实现使用 C++ 或底层汇编优化，性能显著高于脚本层面，绝不能因加载兼容文件而覆盖原生实现。
• 闭包与方法引用缓存（Performance Caching）：在自执行函数中将 Object.prototype.toString 存储在局部变量 nativeToString 中。后续每次调用 Array.isArray 时，省去了沿着 Object -> prototype -> toString 逐层属性查找的开销。
• 严格等于匹配（Strict Equality）：使用 === '[object Array]' 进行字符串比对，杜绝隐式类型转换带来的偶发意外。

六、边界情况与 IE8 特殊行为验证

为了验证该 Polyfill 在极端参数传入时的健壮性，我们可以设计针对各类易混淆对象的测试用例。在 IE8 及其它运行环境中，测试结果均与现代规范完全保持一致。

七、总结与工程选型建议

JavaScript 作为一门弱类型动态语言，类型检测的底层逻辑直接关系到基础类库的稳健性。通过对各个历史方案的对比分析，可以得出如下明确的选型与使用准则：

• 加载时机优先：Polyfill 代码应当置于所有业务逻辑、第三方类库（如 jQuery、Lodash 等）以及模块化加载器执行之前，确保全局执行环境在第一时间具备标准的 ES5 API。
• 摒弃脆弱判断：在编写需要兼顾旧浏览器的前端项目时，坚决避免使用 instanceof Array 作为唯一的数组类型鉴别依据，防止因跨 iframe 调用埋下偶发性 Bug。
• 遵循官方规范：基于 Object.prototype.toString.call 的判定方式与 ES5+ 规范中关于 Array.isArray 的标准行为完全对齐，是目前所有兼容库（如 es5-shim、core-js 等）的统一实现基石。

通过这一简洁而严谨的 Polyfill 方案，我们不仅在 IE8 等旧版本浏览器中彻底解决了数组识别难题，更为跨平台代码的一致性与健壮性打下了扎实的基础。