javascript - Chrome 重新排序对象键(如果是数字)是正常/预期的吗

Question

我注意到某些代码会评估电子商务网站的某些鞋码并将其输出到屏幕上，这会扰乱 Chrome 中的顺序。

给出的 JSON 可以是:

{
  "7": ["9149", "9139", "10455", "17208"],
  "7.5": ["9140", "9150", "10456", "17209"],
  "8": ["2684", "9141", "10457", "17210"],
  "8.5": ["9142", "10444", "10458", "17211"],
  "9": ["2685", "9143", "10459", "17212"],
  "9.5": ["10443", "9144", "10460", "17213"]
}

...将大小减半。

在转换为对象并通过键迭代时，自然顺序受到尊重，它们如下所示:

7, 7.5, 8, 8.5 etc.

但仅在 Chrome 中，“看起来”像整数的键总是首先从对象中出来，因此 for... in 循环的输出是:

7, 8, 9, 7.5, 8.5, 9.5 ...

Object.keys(sizes); // ["7", "8", "9", "7.5", "8.5", "9.5"]

这里是测试用例:https://jsfiddle.net/wcapc46L/1/

它只影响整数，似乎 Webkit/Blink 有一个优化，更喜欢数字对象属性，可能与分支预测或其他有关。

如果您为对象键添加任何字符的前缀，则顺序不受影响并按预期工作 - FIFO

我想我记得读到过，不能保证对象的属性顺序，但同时，这非常烦人，并且单独为 chrome 用户修复它会导致相当大的工作量。

有什么想法吗？这可能是一个会得到修复的错误吗？

edit 另外，我现在发现这是 v8 错误跟踪器上的一个问题:

https://code.google.com/p/v8/issues/detail?id=164

Blink 似乎不想解决此问题，并且仍将是唯一可以解决此问题的浏览器。

update whatever hash table optimisation webkit/blink had, has now made its way into gecko (FF 27.0.1) - https://jsfiddle.net/9Htmq/ results in 7,8,9,7.5,8.5,9.5. applying _ before the keys returns the correct / expected order.

update 2017 People are still upvoting and editing this so - It does NOT appear to affect Map / WeakMap, Set etc (as demonstrated by updated main example)

Answer 1

这是 v8 处理关联数组的方式。一个已知问题 Issue 164但它遵循规范，因此标记为“按预期工作”。循环关联数组不需要顺序。

一个简单的解决方法是在数值前面加上字母，例如:'size_7':['9149','9139'] 等。

该标准将在下一个 ECMAScript 规范中发生变化，迫使 [chrome] 开发人员对此进行更改。