Chrome与Firefox中Object.assign、扩展运算符、循环添属性的性能差异

Chrome（V8引擎）和Firefox（SpiderMonkey引擎）对**多属性对象的浅拷贝操作（扩展运算符/Object.assign）**的优化策略存在本质差异，这是你观察到性能反差的核心原因，具体拆解如下：

1. 批量属性拷贝的底层实现不同 #

• SpiderMonkey针对固定结构的对象拷贝，会触发内存块直接复制的优化（类似C语言的结构体memcpy）。当模板对象的属性数量固定、值均为null时，引擎可以一次性复制整个对象的内存区域，无需逐个遍历属性，因此效率极高。
• V8在处理属性数量较多的对象拷贝时，会走逐个属性遍历复制的路径，即使对象结构完全固定。当属性数量超过某个阈值后，V8不会触发内存块复制的优化，导致拷贝速度远慢于循环逐个添加属性。

2. 隐藏类（Hidden Class）的处理开销差异 #

• V8严重依赖隐藏类来优化对象操作，但当对象属性数量极多时，创建和同步隐藏类的开销会被放大。扩展运算符/Object.assign在拷贝时，需要为新对象同步模板对象的隐藏类结构，这个过程在多属性场景下，反而比循环动态添加属性的隐藏类调整更耗时。
• SpiderMonkey的类型系统对多属性对象的兼容性更好，无需为拷贝操作额外处理复杂的类型同步逻辑，性能表现更稳定。

3. 内联缓存（IC）的命中效率差异 #

• 循环添加属性的操作，在两个引擎中都会被优化为高命中率的内联缓存：因为每次都是向空对象添加相同的属性序列，引擎可以复用缓存的操作逻辑，性能稳定。
• 而扩展运算符/Object.assign的拷贝操作，V8针对多属性对象的内联缓存优化不如SpiderMonkey彻底，每次拷贝都需要重新解析属性列表，无法有效复用缓存，导致性能下降。

额外注意点 #

如果你的createEmptyRow函数是通过动态逻辑（比如循环）生成模板对象，而非静态字面量定义，V8的优化空间会进一步缩小——因为模板对象本身的隐藏类可能不稳定，会额外增加拷贝时的类型处理开销。

实践建议 #

• 在Chrome环境下，针对多属性对象的初始化，循环逐个添加属性反而更高效；
• 若需要跨浏览器兼顾性能，可以考虑根据浏览器环境动态选择实现方式，或者使用构造函数 + Object.defineProperties的方式（提前定义属性描述符，减少动态属性添加的开销）。

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