我最近偶然发现了在 JavaScript 中对数组使用 for..in 循环的问题。
根据this 问题中的答案，for..in 旨在枚举对象的属性，包括继承的属性。
如果是这样，为什么我们能够使用 Object.defineProperty 将属性定义为不可枚举？这不违背 for..in 的全部意图吗？还是被认为是不好的做法，应该避免？
另外，为什么我们首先要以这种方式迭代所有属性（即使用 for..in 循环）？这什么时候能派上用场？
为什么不将所有 (Array) 原型扩展定义为不可枚举并继续使用 for..in 和数组呢？
【问题讨论】：
标签： javascript arrays enumerable for-in-loop
问题在于对象属性只有一个命名空间（暂时忽略 ES2015 中的符号功能）。有些对象属性您确实希望是可枚举的，而有些则不是。包含对象数据和与其他对象关系的属性与方法名称共享该命名空间。
for ... in 循环不仅查看直接涉及的对象的属性，还查看原型链的上游。这可能是不可枚举属性最有可能的用途：您可能希望放在原型对象上的方法可能不需要是可枚举的。
对我而言，在迭代 Array 实例的 numeric-name 属性时不使用 for ... in 的真正原因是无法保证您会以任何特定顺序迭代索引。尽管大多数运行时系统确实以明显的顺序返回数字名称属性，但语言规范绝对不要求这种情况。通过在普通的 for 循环中使用显式数字索引，您可以显式控制迭代顺序。
编写 JavaScript 代码以用于在他们无法控制的情况下运行其他代码的人（想想支持广告的网站，或具有大量指标工具的网站）知道依赖内置原型并不被随机垃圾污染是非常不明智的。使用 for ... in 会使您的代码受制于为该第三方代码做出贡献的最差代码人员。
现代实现有Object.keys()，它返回一个对象的可枚举的“自己的”属性名；也就是说，直接在对象上的属性名称，而不是原型链中的。
【讨论】：
for ... in 可以很好地与数组一起使用。请重新阅读上面的第三段。 Prototype.js 是一个雄心勃勃的项目，我认为虽然这是一个很好的实验，但它有力地证明了扩展系统对象并不是一个好主意。当然，既然大多数 JavaScript 环境都允许使用不可枚举的属性，那么 Prototype 可能就不那么成问题了。 （8 或 9 年前，当我这样做时，我真的很喜欢使用 Prototype。）