手写递归遍历与标准查找的基准测试耗时对比

评估手写递归原型遍历与标准查找方式的时间开销，关键在于现代 JavaScript 引擎（如 V8、SpiderMonkey）是否会针对本次属性访问进行深度优化，而非单纯比较代码行数的多寡。这些引擎在属性访问环节引入了大量运行时优化策略，其中最具代表性的就是内联缓存（IC）。当同一属性被反复读取时，访问速度极快；但若使用动态键名、中途篡改原型链、或首次跨多层查找，则极易触发慢速路径。因此，基准测试必须真实反映这些底层机制的影响，而不能仅仅比较函数的编写长度。

要进行可靠的性能评估，需要严格控制变量、隔离引擎行为，并测量可复现的底层耗时。下面我们将从构建原型链开始，逐步带你掌握完整的测试流程。

构建可控的原型链测试结构

核心思路很简单：让目标属性仅存在于第 N 层原型对象上，而中间所有原型层均不包含该键名，从而强制引擎必须遍历到指定深度才能命中。这样一来，测出的耗时才是“深度查找”带来的真实性能开销。

// 创建 0 层（自身有）
const obj0 = { id: 42 };
// 创建 3 层原型链：obj3 → obj2 → obj1 → obj0
const obj1 = Object.setPrototypeOf({}, obj0);
const obj2 = Object.setPrototypeOf({}, obj1);
const obj3 = Object.setPrototypeOf({}, obj2); // id 只在 obj0 上

需要特别注意以下几个关键点：

• 所有对象统一使用 Object.setPrototypeOf 构建原型链，避免通过 __proto__ 赋值导致引擎优化降级；
• 属性键名保持一致（例如 'id'），且不在中间原型层重复定义；
• 避免使用 eval、with、delete 或动态修改 prototype 属性，防止内联缓存（IC）失效。

将待测操作封装为纯函数

将测试逻辑收拢为无副作用、无外部依赖的纯函数，便于 Benchmark.js 在隔离环境中稳定运行。以下是几种典型的属性查找操作：

// 标准访问（最快路径）
const directAccess = (obj) => obj.id;

// hasOwn 检测（安全、推荐）
const hasOwnCheck = (obj, key) => Object.hasOwn(obj, key);

// 手写递归原型遍历（模拟旧式 polyfill）
const protoWalk = (obj, key) => {
  let current = obj;
  while (current != null) {
    if (Object.prototype.hasOwnProperty.call(current, key)) {
      return true;
    }
    current = Object.getPrototypeOf(current);
  }
  return false;
};

// in 操作符（走原型链，但不区分自有/继承）
const inCheck = (obj, key) => key in obj;

以下几个容易踩坑的地方需要特别留意：

• obj.key !== undefined 不能作为属性存在性检测，应直接避免使用；
• obj.hasOwnProperty(key) 调用方式不安全，务必使用 Object.prototype.hasOwnProperty.call 确保健壮性；
• protoWalk 函数中每次迭代都会调用 Object.getPrototypeOf 和 hasOwnProperty.call，这两部分的开销必须纳入最终耗时统计。

借助 Benchmark.js 进行函数级压力测试

安装方式：npm install benchmark，然后运行以下示例脚本：

const Benchmark = require('benchmark');
const suite = new Benchmark.Suite();

suite
  .add('direct access', () => directAccess(obj3))
  .add('Object.hasOwn', () => hasOwnCheck(obj3, 'id'))
  .add('"in" operator', () => inCheck(obj3, 'id'))
  .add('handwritten proto walk', () => protoWalk(obj3, 'id'))
  .on('cycle', (e) => console.log(String(e.target)))
  .on('complete', () => console.log('Fastest is ' + this.filter('fastest').map('name')))
  .run({ async: false });

关键配置要点：每个测试项必须使用完全相同的输入对象（例如 obj3）；测试体内避免创建新对象或调用 console.log；运行前确保 JIT 编译器已完成预热（Benchmark.js 默认会处理）。重点关注 Hz（每秒可执行次数）以及误差范围 ±%——若误差超过 1.5%，说明系统干扰较大，需要重新运行测试。

借助 DevTools 精准定位性能瓶颈

基准测试能告诉你“哪个操作更慢”，而 DevTools 能揭示“为什么慢”：

1. 在 Chrome 中打开 Developer Tools → Performance 面板；
2. 点击录制，运行一段密集调用（例如 for (let i = 0; i < 1e5; i++) protoWalk(obj3, 'id')）；
3. 停止录制后，仔细分析火焰图：
   • 如果出现大量 GetPropertyStub？→ 说明未命中内联缓存（IC），走的是通用属性获取路径；
   • 如果看到 LoadIC_Miss？→ 表示引擎无法缓存当前访问模式（常见原因包括键名非常规、原型被动态改写）；
   • Object.getPrototypeOf 占用比例偏高？→ 说明手写遍历带来了固有开销；
   • 调用栈中是否存在 FunctionCall 层层嵌套？→ 递归本身会引入额外的帧管理成本。

通过对比可以发现：directAccess 几乎全部命中 LoadIC_Hit；而 protoWalk 会反复触发 GetPropertyStub 与 GetPrototype，且无法被内联优化。

避开常见的性能评估误区

• ✅ 正确做法：将属性仅设置在原型链的最深层，其他原型层保持干净，这样才能测出“深度查找”的真实代价；
• ❌ 错误做法：直接使用 {} 字面量进行测试——引擎对字面量对象存在特殊优化，测试结果会失真；
• ❌ 错误做法：混用 obj.__proto__.x 进行访问——V8 已弃用该方式且会禁用 IC，必然导致性能下降；
• ❌ 错误做法：测试 obj.x = 123 赋值操作——写入路径与读取路径的优化策略完全不同，两者不具备可比性。

真正决定性能的关键，从来不是“递归遍历了多少层”，而是“JavaScript 引擎能否将该操作编译为一条内存偏移指令”。能，则快；不能，则退化为解释执行并伴随多次原型跳转。道理并不复杂，但却很容易被忽视。