v8中多态属性访问导致内联缓存失效并降级为超多态慢路径，而非搜索隐藏类；典型诱因包括参数结构不一致、动态增删属性、属性类型变更等，引发每次访问都走完整查找流程。

JS 编译器（尤其是 V8）在处理“多态”属性访问时，并不是真的去“搜索”隐藏类，而是因类型不一致导致内联缓存（IC）失效，被迫退回到慢路径——这比“搜索”更耗时，也更隐蔽。

多态访问不是查表，而是缓存崩塌

内联缓存本意是：第一次访问 obj.name 时记录下 obj 的隐藏类和 name 的内存偏移，后续调用直接按偏移取值，快如闪电。但当同一函数被传入不同隐藏类的对象（比如 {name: 'a'}、{name: 'b', id: 1}、{name: 123}），V8 最多支持 4 种类型缓存；超过后 IC 进入“多态模式”，再之后就降级为“超多态”（megamorphic），彻底放弃缓存，每次都要走完整属性查找流程。

• 不是“慢慢找”，而是“每次重走最慢的路”——从对象头开始查隐藏类，再查字典或线性扫描
• 典型表现：函数执行时间从纳秒级跳到百纳秒甚至微秒级，尤其在循环或动画帧中会被放大
• Chrome DevTools 的「Performance」面板里能看到 GetPropertyStub 或 LoadIC_Megamorphic 占比突增

业务代码里最常见的多态诱因

这些写法看似无害，却极易触发多态，且常出现在高频逻辑中：

Wjs Uploading Video

将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。

下载

• 统一接口接收结构不一致的数据：比如一个 renderItem(item) 函数，既处理 API 返回的 {id, title, tags[]}，又处理本地 mock 的 {id, title}，还混入编辑态的 {id, title, isEditing}
• 构造后动态补属性：const user = {id: 1}; if (isAdmin) user.role = 'admin'; —— 同一构造逻辑产出不同隐藏类
• 属性值类型随意变更：item.count = 0; … item.count = 'loading'; … item.count = null; —— V8 会将该属性标记为“泛型”，IC 失效
• 用 Object.assign({}, a, b) 合并对象：若 a 和 b 属性顺序/存在性不同，结果对象隐藏类不可预测

真正有效的缓解策略

不是消灭多态（有时不可避免），而是把多态控制在低频、可预测、非关键路径上：

• 对高频函数的参数做“形状守门”：用 hasOwnProperty('x') && typeof obj.x === 'string' 预判，或提前归一化（如 normalizeItem(item) 统一补全默认字段）
• 构造函数中声明全部预期属性（含默认值）：function User(data) { this.id = data.id || 0; this.name = data.name || ''; this.role = ''; }
• 避免在热路径中使用 in、for...in、Object.keys() —— 它们强制触发完整属性枚举，绕过 IC
• 对纯数据容器（如配置项、映射表），改用 Map 或 new Object(null)，明确告诉引擎“这里不走原型链，也不需要隐藏类优化”

验证是否真被多态拖慢

不要猜，用工具定位：

• Chrome DevTools → 「Memory」→ 拍摄堆快照 → 筛选 Object 类型 → 查看相同构造函数下的对象是否拥有高度分散的 HiddenClass（需开启 --trace-hidden-classes 启动 Chrome）
• Node.js 下运行 node --trace-opt --trace-deopt script.js，观察是否有 deoptimized 或 concurrent recompilation 日志
• 用 %HasFastProperties(obj)（仅 d8 或启用 --allow-natives-syntax 的 Node）检查对象是否已进入字典模式