反馈向量是V8运行时记录类型与隐藏类信息的观测日志，不直接跳转；其IC插槽状态演化驱动TurboFan优化与反优化跳转。
V8 的反馈向量（Feedback Vector）本身不执行跳转，也不直接决定层级跳转逻辑；它是一张运行时“观测日志”，记录函数各调用点（IC，Inline Cache）上实际遇到的类型、隐藏类（Map）、调用频次等信息。真正驱动层级跳转（如从解释执行 → TurboFan 优化代码 → 反优化回退）的，是这些反馈数据触发的编译决策与执行路径切换。理解这个过程，关键在于把反馈向量看作跳转逻辑的因果线索，而非跳转本身。
反馈向量如何映射到 Crankshaft/TurboFan 的层级跳转
- 反馈向量中每个插槽对应一个 IC 点（例如
o.x属性读取、arr.push()调用、+运算） - 插槽状态演化（
uninitialized → monomorphic → polymorphic → megamorphic）直接反映该点的类型稳定性 - Crankshaft（已弃用）和 TurboFan 都依赖这些状态做编译策略：
- 单态（monomorphic）：认为类型稳定，可生成专用内联代码，启用 TurboFan 编译
- 多态（polymorphic）：插入多个隐藏类比对 + 分支跳转，仍可能优化，但代码膨胀、分支预测压力增大
- 超多态（megamorphic）：放弃优化假设，强制走通用慢路径（如
GetProperty运行时调用），TurboFan 通常跳过此类函数或快速反优化
举例：
function sum(a, b) { return a + b; }
若前 100 次都传入数字，反馈向量中+运算插槽标记为 monomorphic → TurboFan 编译为整数加法指令；第 101 次传入字符串"1"+"2"，触发deoptimize，执行流立即跳转回 Ignition 字节码解释器，再走通用ToString+StringConcat路径。
如何用反馈向量诊断跳转频繁的原因
- 启动 Node.js 时加
--trace-ic，观察 IC 状态变化节奏：node --trace-ic script.js # 输出类似：LoadIC at 0x1234: uninit → monomorphic → polymorphic (after 12 calls)
- 对目标函数执行
%DebugPrint(func)，定位其反馈向量地址，再%DebugPrint(feedback_vector)查看各插槽详情 - 关注三类高风险信号：
- 某个 LoadIC/StoreIC 插槽长期卡在
polymorphic，说明该属性访问持续混用不同结构对象（如{x:1}和{x:1,y:2}交替） - CallIC 插槽快速升至
megamorphic，往往因回调函数类型不一（如array.map(fn)中fn每次不同） -
kConstructStub或kKeyedLoadIC插槽反复重置，暗示原型链变动或动态属性增删（如obj.__proto__ = newProto）
- 某个 LoadIC/StoreIC 插槽长期卡在
TurboFan 优化与反优化的跳转触发条件
TurboFan 不是“一次性编译完就固定运行”，而是在运行中持续响应反馈变化：
- 优化启动条件：函数被识别为热点（默认执行超 1000 次），且关键 IC 插槽处于 monomorphic 或有限 polymorphic（≤ 4 种 Map）
-
反优化触发点：
- 某次调用打破 TurboFan 假设（如优化版只处理 number，却传入 object）
- 隐藏类发生变更（如向已优化对象新增属性，导致 Map 升级）
- 全局对象被修改（如
Array.prototype.push = myPush，使所有arr.push()CallIC 失效）
- 每次反优化都会清空当前机器码，跳转回 Ignition，并标记该函数“暂不重优化”，需重新积累稳定反馈
提示：可用
--trace-deopt查看反优化堆栈，配合--print-opt-code观察生成的汇编中哪些位置嵌入了 deopt 检查点（如test rax, rax; jz deopt_entry_0x1234）
不复杂但容易忽略
