多态属性访问是JS引擎性能退化信号，指同一属性读取操作在多次调用中目标对象类型或字段布局不一致，导致JIT无法锁定偏移而插入查表与分支判断，实测比单态慢3–5倍。
多态属性访问在 JS 引擎（如 V8）中不是“优化完成态”，而是性能退化信号——它意味着 JIT 编译器无法锁定字段偏移、类型布局或原型链路径，被迫插入额外查表、分支判断和 fallback 跳转，直接拖慢热点代码执行速度。
什么是多态属性访问？
指同一属性读取操作（如 obj.x）在多次调用中，目标对象属于多个不同构造函数，或同一构造函数但字段布局不一致（如有的加了 __slots__、有的没加，或动态增删过属性）。
常见触发场景：
- 数组元素混入不同类实例：
[new Point(1), new Circle(2), new Line(3)]后统一访问.x - 对象被反复
delete obj.x再赋值，导致隐藏类（hidden class）链断裂 - 使用
Object.assign({}, a, b)或展开运算符拼接对象，破坏原始构造器信息 - TS 类型注解（如
obj: Point | Circle）不影响运行时行为，不阻止多态发生
V8 多态内联缓存（Polymorphic Inline Cache）怎么工作？
当 obj.x 出现 2–4 种不同接收者类型时，V8 不会立即退到解释器，而是生成带条件跳转的机器码，查一个小型类型-偏移映射表（polymorphic IC table）：
- 每次访问先比对
obj->map是否匹配缓存中的某一项 - 命中则用对应偏移加载字段；不命中则走 slow-path，更新缓存或触发去优化（deoptimization）
- 超过 4 种类型（具体阈值依 V8 版本而定），标记为
megamorphic，IC 表失效，每次访问都走完整GetProperty查找链
这比单态访问多出至少 2 次比较 + 1 次间接跳转，实测循环中多态访问比单态慢 3–5 倍（基于 V8 12.3–13.1 测试数据）。
业务代码里哪些写法会悄悄引入多态？
不是语法错误，但会在高频路径上埋下性能雷：
-
for (const item of list) { total += item.value; }—— 若list是混合类型的Array，item.value极易多态 -
obj[key] = val中key是变量且取值不固定（如['x', 'y', 'z']随机轮换），破坏属性访问的 monomorphic 路径 - 用
Object.create(null)创建对象后频繁增删属性，导致无稳定 hidden class 可跟踪 - Class 继承链中子类覆盖父类同名字段但未保持内存布局一致（如父类用
this.x = 0，子类用Object.defineProperty设置 getter）
注意：delete 操作本身就会强制对象 transition 到 dictionary mode，彻底关闭所有基于 hidden class 的优化。
怎么验证你的代码是否掉进多态陷阱？
V8 提供运行时诊断能力，不需要改业务逻辑：
- 启动 Node.js 时加
--trace-ic：输出每处属性访问的 IC 状态（monomorphic/polymorphic/megamorphic） - 用
%DebugPrint(obj)（需--allow-natives-syntax）查看对象当前 map 和是否处于 dictionary mode - Chrome DevTools → Performance 面板录制后，在 Bottom-Up 视图中筛选
GetProperty或LoadField，看是否集中在某几行
真正难的是：多态往往藏在抽象层之下。比如一个通用 render(item) 函数被 12 个组件复用，其中 3 个传入结构不一致的对象——问题不在 render，而在那 3 个调用点的输入契约模糊。
