Chrome环境下for...in循环首次运行极速、后续运行变慢的原因分析（附与Object.keys(obj).length的性能对比测试）

这是个非常有意思的性能现象，核心原因得从Chrome背后的V8 JavaScript引擎的JIT（即时编译）优化策略说起，尤其是TurboFan编译器的行为差异：

1. 首次运行的激进优化让for...in“超常发挥” #

当你第一次跑测试时，V8的TurboFan编译器会针对当前测试对象的结构做出非常激进的假设：比如认定这个对象的自有属性数量固定、没有从原型链继承的可枚举属性，甚至会直接把for...in的遍历逻辑内联到代码里，跳过了很多通用场景下的检查步骤。

这种极度简化的执行路径让for...in的速度快得离谱——甚至超过了Object.keys(obj).length，毕竟后者还要额外创建一个属性数组再取长度，有固定的内存分配开销。

2. 后续运行触发“去优化”，for...in打回原形 #

第二次运行时，V8的优化器会触发**去优化（Deoptimization）**操作，直接废掉之前的激进优化：

• 一方面，第一次运行后的垃圾回收可能改变了对象的内存布局，打破了TurboFan之前的假设；
• 更关键的是，V8对for...in的优化稳定性远不如Object.keys：for...in天生要处理原型链上的可枚举属性，哪怕你的测试对象没有原型属性，后续运行中优化器可能会“保守起见”，重新启用通用的遍历逻辑（比如强制检查原型链），不再维持之前的激进优化；
• 还有可能是第一次运行的优化缓存被清空，TurboFan重新编译时采用了更稳妥的策略，避免因为对象结构潜在变化导致错误，这直接让for...in的执行时间大幅飙升。

3. Object.keys的性能为啥一直稳定？ #

Object.keys(obj).length的性能之所以稳，是因为V8对它的实现做了高度优化且逻辑固定：
它直接读取对象隐藏类（Hidden Class）里记录的自有属性数量元数据，创建数组的开销是固定的，而且不会因为后续运行的环境变化（比如垃圾回收、缓存清空）触发去优化，所以每次运行的耗时都相差无几。

小补充：如果你的测试对象是用Object.create(null)创建的无原型纯对象，for...in的性能稳定性会提升不少——因为V8可以确定不需要遍历原型链，优化策略会更持久。

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