JavaScript中integer index定义与引擎属性排序表现的疑问

核心问题的本质 #

你观察到的差异，是ECMA262规范的integer index定义与JS引擎实际实现的妥协结果——规范里的integer index覆盖[0, 2^53-1]的正整数（含+0）的规范数字字符串，但主流引擎（Node.js、Deno、Bun等）在属性排序时，仅优先处理[0, 2^32-2]范围内的索引，这并非引擎违反规范，而是基于性能和底层实现的合理选择。

为什么引擎用[0, 2^32-2]作为优先排序范围？ #

这个范围和ECMA262中array index的定义完全一致（0 ≤ i < 2^32-1），原因在于：

• JS数组的底层实现依赖32位无符号整数的内存寻址逻辑，超过2^32-2的索引无法触发数组的连续内存优化，会被当作普通字符串属性存储。
• 引擎在属性排序时，优先处理的是能被优化为数组索引的属性，而非所有符合integer index定义的键——实际开发中几乎不会用到2^32-2以上的数组索引，这种优化不会影响绝大多数场景的语义，却能大幅提升排序性能。

规范需要调整吗？ #

不需要。原因如下：

• integer index是一个宽泛的概念，涵盖所有符合数字字符串规则的键；而array index是它的子集，专门对应数组的优化存储场景。规范的定义并没有错误，只是引擎在实现时，选择将排序优先级限定在更实用的array index范围内。
• ECMA262的属性排序规则仅要求“integer index属性按升序排列”，但并未强制要求所有integer index都必须纳入优先排序队列。引擎的实现属于不违反核心语义的性能优化，符合规范的灵活性要求。

你可能遗漏的关键细节 #

1. 数组length的边界限制：数组的length属性最大值为2^32-1，因此arr[2^32-1]及更大的索引会被当作普通对象属性，不会改变数组的length。引擎在排序时也遵循这一逻辑，将此类索引归为普通字符串属性。
2. 行业共识的默认实现：所有主流JS引擎都统一采用array index范围作为优先排序的边界，这已经成为事实上的标准。规范虽未修改integer index的定义，但也认可了这种符合实际需求的实现方式。

内容的提问来源于stack exchange，提问作者Sergey Shandar