多态属性访问指同一属性读取点被多个不兼容类型（如不同构造器实例）调用，触发v8多态内联缓存路径，导致性能降速3–5倍；其本质是字节码位置类型分布发散，迫使引擎放弃单态优化，转为低效通用路径。
多态属性访问会显著拖慢 JS 执行速度，不是“有点慢”，而是可能让热点代码降速 3–5 倍——它直接触发 V8 的多态内联缓存（Polymorphic Inline Cache）路径，被迫走查原型链、做多次类型判断、反复哈希查找属性，最终生成带分支预测的通用机器码，而非单态下的硬编码内存加载指令。
什么是多态属性访问（V8 视角）
当同一个属性读取点（如 obj.x）在短时间内被不同构造器的实例调用时，V8 就标记为多态。例如：
const p1 = new Point(1, 2); const p2 = new Vector(3, 4); console.log(p1.x, p2.x); // 同一位置访问 x，但 p1 是 Point 实例，p2 是 Vector 实例
此时 V8 不再信任单一类型路径，放弃单态优化，转而维护一个最多 4 个类型的内联缓存（IC）槽位。一旦超过（比如又来了 Circle、Rect），就退化为巨态（megamorphic），彻底禁用 IC，每次访问都走 _GetProperty 全流程：查原型、比对 key、哈希定位字典项。
- 多态 ≠ 多个类有同名字段，而是「同一字节码位置」被多个不兼容类型命中
- 即使两个类结构完全一样（
class A {x=0},class B {x=0}），只要构造器不同，V8 就视为不同类型 - 箭头函数、对象字面量、
Object.create(null)创建的对象也会各自形成独立类型槽位
多态访问的真实开销在哪
开销不在“看起来多写了几行”，而在底层执行路径的不可预测性：
- 每次访问都要执行至少 2 次类型比较（当前对象类型 vs 缓存中每个候选类型）
- 失败时触发 deoptimization，丢弃已编译的代码，回退到解释器，再重新收集反馈、重编译
- 生成的机器码含
cmp+je分支，CPU 分支预测失败率升高，流水线清空代价明显 - 无法将
obj.x内联为类似mov eax, [rdi + 16]的单指令，必须保留查找逻辑
实测：在密集循环中访问多态 x 字段，比单态慢 3.7×；若已进入巨态，慢 5.2×（基于 V8 12.4，Intel i7-11800H）。
哪些写法会悄悄触发多态
开发者常以为“只要没写 if (obj instanceof X) 就安全”，其实很多日常操作都在埋雷：
- 用工厂函数返回不同类实例：
createShape('circle')和createShape('rect')返回不同构造器对象，却都传给同一处理函数 - 混用 class 实例与 plain object：
process({x:1, y:2})和process(new Point(1,2)) - 动态增删属性：
obj.x = 1; delete obj.x; obj.x = 2;—— 这会改变隐藏类（hidden class），导致 IC 失效并重建 - 使用
Object.assign({}, a, b)合并对象，新对象隐藏类与原对象不同，打破单态连续性
特别注意：__proto__ 修改、Object.setPrototypeOf()、或任何修改原型链的操作，都会立即污染所有依赖该原型的 IC 状态。
业务影响不只是“页面卡一点”
多态本身不是 bug，但它是性能劣化的早期信号，尤其在以下场景会放大后果：
- 动画帧回调（
requestAnimationFrame）中访问多态属性 → 直接掉帧，用户感知为“卡顿” - 数据表格滚动时反复读取
row.id、row.status→ 若 row 来源混杂（API 返回、mock 数据、编辑态临时对象），IC 快速饱和 - 状态管理库中 selector 访问嵌套字段（如
state.user.profile.name）→ 一旦 state 结构在开发期被 patch 或 mock 扰动，生产环境就可能因类型不稳而降级 - Web Worker 中批量处理对象数组 → 多态使 JIT 编译时间变长、代码缓存命中率下降，首屏后延迟更明显
最隐蔽的问题是：它往往只在特定数据组合下暴露，测试难覆盖，上线后靠用户反馈才发现——而那时你已经没法快速定位是哪个 .x 访问拖垮了整个模块。
