<p>yield* 本身不被V8内联缓存（IC）优化，真正可被IC加速的是迭代器的.next()方法调用，前提是对象结构稳定且调用方式一致。</p>
yield* 后面跟自定义可迭代对象时，V8 的内联缓存（IC）并不直接参与优化——这不是它负责的环节。
内联缓存只作用于两类高频操作：
- 对象属性访问（如
obj.x） - 方法调用（如
obj.method()）
而 yield* 展开的是迭代协议（[Symbol.iterator]() 返回的迭代器），整个过程走的是 迭代器状态机路径，由 V8 的生成器运行时（Generator Runtime）和迭代器协议实现共同处理，不触发 IC 机制。
yield* 的实际执行链条
-
yield* iterable会调用iterable[Symbol.iterator]() - 得到一个迭代器对象（必须有
.next()方法） - 然后反复调用
.next()，把每次返回的value逐个yield出去 - 这些
.next()调用本身 可能 受益于 IC ——但前提是：- 迭代器对象结构稳定（隐藏类一致）
-
.next是普通函数属性（非 getter、非 Proxy、非动态计算） - 所有
yield*出现在同一代码位置，且反复作用于同类迭代器
为什么你容易误以为 IC 在“优化 yield*”
常见混淆点来自以下现象：
- 同一构造函数创建的多个迭代器，在循环中被
yield*多次展开，性能很好 - 一旦混入不同类的迭代器（比如数组 + 自定义类 + generator 函数），性能明显下降
这表面像 IC 生效/失效，实则是：
- TurboFan 对生成器做了类型反馈聚合，为常见迭代器形状生成专用内联代码
- 但底层支撑仍是：
.next()调用是否能稳定命中单态 IC - 若
iter.next()总是同一个隐藏类的对象方法，V8 就能内联该调用并缓存偏移 - 若
iter类型多变（比如yield* obj有时是数组、有时是 Map、有时是手写迭代器），.next调用退化为多态甚至 megamorphic，失去加速效果
如何让 yield* 实际受益于 IC
确保迭代器对象满足 IC 友好条件：
- 所有迭代器实例由同一构造函数创建，且属性顺序、初始值完全一致
- 在构造函数中一次性声明所有属性（包括
next方法），避免后续增删 - 不用
Object.defineProperty或Proxy包装迭代器（破坏隐藏类稳定性） - 避免在
yield*前后穿插iter['next']()或Reflect.get(iter, 'next')（污染该调用点的 IC 状态）
例如：
class RangeIterator {
constructor(start, end) {
this.start = start; // 提前声明
this.end = end; // 提前声明
this.current = start; // 提前声明
}
next() { // 普通方法，非 getter
if (this.current < this.end) {
return { value: this.current++, done: false };
}
return { done: true };
}
[Symbol.iterator]() { return this; }
}
// ✅ 安全：每次 yield* 都面对同构迭代器
function* gen() {
yield* new RangeIterator(0, 100);
yield* new RangeIterator(100, 200); // 同类对象，IC 可复用
}关键结论
-
yield*本身不被 IC 加速，它只是语法糖，背后是标准迭代协议调用 - 真正能被 IC 加速的，是迭代器上的
.next()方法调用（前提是调用方式稳定、对象结构稳定） - 把
yield*当作“黑盒加速点”是误解；优化重点应放在迭代器对象的构造一致性和.next()访问模式的稳定性上
不复杂但容易忽略
