如何理解原型继承中“隐式原型引用（[[Prototype]]）”在 JIT 优化中的 Guard 角色-js教程-PHP中文网

[[prototype]]是jit优化的关键守门人，通过prototype chain、hidden class和inline cache三类guard保障属性访问性能；其变更会触发去优化，故应避免运行时修改。

如何理解原型继承中“隐式原型引用（[[prototype]]）”在 jit 优化中的 guard 角色

在原型继承中，[[Prototype]] 是对象内部的一个隐藏属性，指向其原型对象。它不暴露给 JavaScript 代码直接访问（obj.__proto__ 是非标准但广泛支持的访问方式），而是由引擎底层维护，用于支撑 obj.prop 这类属性查找——当属性不在对象自身时，引擎会沿着 [[Prototype]] 链向上查找。

JIT 编译器（如 V8 的 TurboFan、SpiderMonkey 的 Warp、或 JSC 的 B3）在优化属性访问时，会把“从某个对象读取某个属性”编译成高度特化的机器码，前提是它能确信该访问路径稳定、可预测。而 [[Prototype]] 就是这个确定性的关键守门人（Guard）。

什么是 Guard？

Guard 是 JIT 生成的运行时检查指令，用来验证“当前对象的结构是否仍符合编译时的假设”。一旦检查失败（即实际运行时结构变了），JIT 就会去优化（deoptimize）——退回到解释执行或重新编译更保守的版本。

[[Prototype]] 直接参与三类核心 Guard：

Prototype Chain Guard
JIT 会记录：
obj.[[Prototype]] === A 且 A.[[Prototype]] === B 且 B.hasOwn('x') === true
这样就能把 obj.x 编译为“跳过 obj → 直接从 B 读 x”的单次内存加载。
若运行中 A.__proto__ = C 或 delete B.x，Guard 失败，触发去优化。
Hidden Class / Shape Guard（与 [[Prototype]] 强耦合）
对象的隐藏类（V8）或结构（JSC）不仅包含自有属性布局，还隐式绑定其 [[Prototype]]。
比如：
```
const a = { x: 1 };
const b = Object.setPrototypeOf({ y: 2 }, a);
```
b 的隐藏类就编码了“自身有 y，原型是 a”。改 b.__proto__ 就会让隐藏类失效，导致所有基于该类的 JIT 代码失效。
Inline Cache (IC) Guard
属性访问首次执行时，内联缓存会记录：
key: 'x', receiver shape: S, prototype chain hash: H, result location: offset_in_B
下次调用若 obj 的 shape 和 [[Prototype]] 链哈希都匹配，就直接取值；否则进入慢路径查链。

为什么 `[[Prototype]]` 变更代价高？

它不是局部变更：Object.setPrototypeOf(obj, newProto) 不仅影响 obj，还会使所有以 obj 为原型的对象的隐藏类/IC 失效（因为它们的 [[Prototype]] 链被污染）。
JIT 无法静态推断动态原型操作，所以只要代码中出现 setPrototypeOf、__proto__ =、或 class X extends Y 中 Y 是动态表达式，相关函数通常直接禁用内联和形状优化，退化为通用查找路径。

实际影响示例

function getFoo(o) {
  return o.foo; // JIT 希望这里稳定
}
const proto = { foo: 42 };
const obj = Object.create(proto);

getFoo(obj); // ✅ 快：JIT 编译为直接从 proto 读 foo
Object.setPrototypeOf(obj, { foo: 99 }); // ⚠️ 破坏 Guard
getFoo(obj); // ❌ 去优化 → 降级为慢路径（遍历原型链）

现代引擎（如 V8 10.9+）会对 setPrototypeOf 做写屏障（write barrier），立即通知所有依赖该原型链的 IC 和优化代码失效，避免错误结果。