FeedbackVector本身不耗时，它只是记录器；真正拉开单态和多态执行耗时差距的是V8后续生成的机器码质量与运行时检查开销。单态下属性访问可编译为一条指令，多态则需多次map比对、分支跳转及慢路径回退，显著增加延迟。

FeedbackVector 本身不耗时，它只是记录器；真正拉开单态和多态执行耗时差距的，是 V8 后续生成的机器码质量与运行时检查开销。

---

FeedbackVector 状态如何影响 JIT 编译决策

V8 的优化编译器（TurboFan）是否为某个函数生成高效机器码，高度依赖 FeedbackVector 中各插槽的状态：

• 单态（monomorphic）：插槽只记录过一种隐藏类 → V8 认为类型稳定，可安全内联属性访问、省略隐藏类比对、直接硬编码字段偏移量
• 多态（polymorphic）：插槽记录了 2–4 种隐藏类 → V8 生成带分支跳转的通用代码，每个分支对应一种隐藏类结构，需运行时比对 map
• 超多态（megamorphic）：插槽记录 ≥5 种隐藏类，或含访问器/Proxy → V8 放弃优化编译，回退到解释执行（Ignition）或极简编译（Sparkplug），几乎不缓存任何中间结果

关键点在于：单态函数大概率走 TurboFan 高度优化路径，而多态函数常触发慢路径跳转、额外的 Map 比对、甚至 IC miss 后的 C++ 回退 —— 这些才是耗时主因。

---

单态 vs 多态在属性访问上的典型耗时差异

以 o.x 访问为例，不同状态下的实际执行逻辑差异极大：

• 单态下可能编译为：

  mov eax, [rdi + 0x10]

  （一条指令，直接按已知偏移加载）

• 多态下可能编译为：

  cmp [rdi + 0x8], map1<br>jz load_x_from_map1<br>cmp [rdi + 0x8], map2<br>jz load_x_from_map2<br>jmp slow_path

  （至少 4 条指令 + 分支预测压力 + 可能的 pipeline stall）

更严重的是：多态会破坏 CPU 分支预测器准确性。实测中，当某 LoadIC 调用点长期处于多态状态，其分支预测失败率可从 30%，导致平均每次访问多出 10–15 个周期延迟。

---

如何用 --trace-ic 快速定位多态热点

启动 Node.js 时加参数即可捕获真实调用点演化过程：

node --trace-ic script.js

输出中重点关注这类行：

LoadIC at 0x12345678: uninit → monomorphic → polymorphic

• 如果某行反复出现 polymorphic 或 megamorphic，说明该位置持续接收结构不一致的对象
• 常见诱因包括：
  • 同一函数既处理 {x: 1} 又处理 {x: 1, y: 2, z: 3}
  • 对象由不同构造函数创建但被混用（如 class A 和 class B 都有 x 字段）
  • 使用 Object.assign({}, a, b) 动态拼接对象，破坏隐藏类稳定性

此时不要急着改 FeedbackVector —— 它不可手动干预；应收敛输入类型，比如拆分函数、提前断言、或改用 ArrayBuffer/TypedArray 替代泛型对象。

---

多态的“隐性成本”常被低估

很多人只关注函数体执行时间，却忽略多态引发的连锁反应：

• TurboFan 不会为多态函数生成内联缓存友好的代码，导致后续所有同名属性访问（哪怕在别的函数里）也难进入单态
• 多态函数无法被 V8 的函数去虚拟化（de-virtualization）优化，间接阻碍整个调用链的优化传播
• 在长时间运行的服务中，多态状态一旦固化，即使后续输入变稳定，V8 也不会自动“降级”反馈状态 —— 必须重启进程或触发显式去优化（%DeoptimizeFunction）

真正要盯住的不是 FeedbackVector 本身，而是它背后暴露的类型契约断裂点。那里才是性能瓶颈的源头。