JavaScript 数组遍历陷阱：为何 for...in 会引发兼容性问题

为什么避免使用 for...in 语句

jqModal 这款 jQuery 插件想必许多开发者都曾接触过。在其源码内部存在一个名为 hs 的函数，其中包含一段嵌套循环代码。

 
for(var i in {jqmShow:1,jqmHide:1})
for(var s in this[i])
if(H[this[i][s]])
H[this[i][s]].w[i](this);
return F;
} 

上述代码中，第一个 for...in 循环的目标是一个匿名对象，这种用法本身没有问题。

然而，根据上下文判断，第二个 for...in 循环遍历的对象 this[i] 实际上是一个数组（Array 类型）。

许多 JavaScript 资深开发者都曾警告过：不应使用 for...in 语句来遍历数组对象。这不仅涉及性能问题，更可能引发难以预料的 Bug。正如俗语所说，不听先人言，吃亏在眼前。

本文以 jqModal 为例，具体说明这种 Bug 在何种场景下发生，旨在引起开发者的重视与警惕。

核心关键词：原生 Array 类、扩展 Array 类

使用 for...in 遍历数组对象的潜在 Bug 在于：如果原生 Array 类被其他 JavaScript 库通过原型链进行了扩展（例如添加了 toJSON 方法，即 Array.prototype.toJSON = xxxx），那么对扩展后的数组使用 for...in 遍历，其逻辑将与遍历原生数组时产生显著差异。

问题重现

以下是一个简单的示例：

 
var x=[1];
for(var s in x){
alert(s);
}; 

按照常规理解，如果 Array 是原生 JavaScript 类，上述代码应仅执行一次 alert 弹窗，且变量 s 的值为数组索引 0。但是，如果 Array 类被扩展并新增了 toJSON 方法，上述代码将执行两次 alert。第一次 s 为索引 0，第二次 s 则变为方法名 'toJSON'。

如果你的代码逻辑基于原生 Array 类设计，而某天同事在页面中引入了一个扩展了 Array 类的第三方 JS 库，结果将难以预测，原有代码逻辑可能因此失效。

这类扩展原生 JS 类的库中，最著名的当属 prototype.js，它为 Array 类扩展了 toJSON、each 等众多方法。这也解释了为何 jQuery 创始人曾对 prototype.js 表示不满（不少开发者因特殊原因在同一页面同时使用 jQuery 和 prototype.js，常遇到意料之外的冲突，仅靠 noConflict 往往无法彻底解决）。此外，若 jqModal 的作者阅读此文，或许也会抱怨 prototype.js，认为：“使用 for...in 遍历数组本就不明智，但更糟糕的根源在于 prototype.js。”

综上所述，如果你在使用 jqModal 的同时，因其他原因也在使用 prototype.js，那么你很可能会遇到冲突。这种冲突会导致 jqModal 的弹窗在 IE6 和 IE7 环境下，无法通过 closeClass 设置的按钮自动关闭。通过跟踪调试代码可以发现，异常点正是本文开头提到的 hs 方法中的 for...in 循环。

解决方案

解决方案：在遍历数组的地方，使用传统的 for 循环（如 for (var i = 0; ...)）或 for...of 语句替代 for...in。