V8 不处理“异步多态属性”，因异步与多态无关；多态指属性访问点遭遇不同隐藏类致内联缓存失效，根源是对象结构不稳定，如初始化顺序不一、动态增删属性、类型变更或构造后补字段；规避关键在于对象创建时固化形状，如构造函数中预设全部属性、避免 delete、兜底填充缺失字段，或对不确定结构改用 Map；验证应关注 IC 状态与隐藏类稳定性，而非是否在 async 函数中。
JS 编译器（如 V8）本身不直接处理“异步多态属性”这个概念——它并不存在于语言规范或引擎设计中。这是一个容易混淆的术语组合，需先拆解澄清：
“异步”和“多态属性”在 V8 中本质无关
• “异步”指执行时机（如 Promise.then、await），不影响对象结构或属性访问路径；
• “多态”在 V8 语境中特指同一处属性访问点（IC site）反复遇到不同隐藏类或类型，导致内联缓存（Inline Cache）失效，触发慢速查找路径；
• 属性访问是否“多态”，只取决于该访问发生时对象的实际隐藏类和属性类型，与代码是否在 async 函数里、是否 await 过，完全无关。
真正造成隐藏类搜索损耗的，是对象结构不稳定
损耗发生在属性读取瞬间，根源是 V8 无法复用优化信息。常见触发场景包括：
- 同一批对象初始化顺序不一致：
const a = {x: 1, y: 2}; const b = {y: 2, x: 1};→ 生成两个互不兼容的隐藏类 - 运行时动态增删属性：
obj.status = 'ok'; delete obj.status;→ 强制对象降级为字典模式，后续所有属性访问退化为哈希查找 - 属性类型反复变更：
obj.count = 1; obj.count = 'done';→ V8 标记该属性为“不稳定”，放弃内联缓存优化 - 构造后补字段：
const u = new User(id); u.name = 'Alice'; u.role = 'admin';→ 每次赋值都可能切换隐藏类，破坏批量对象的一致性
规避的关键：让对象从诞生起就“静态可预测”
不是写 async/await 时要小心，而是在对象创建那一刻就要固化形状：
- 构造函数中一次性声明全部预期属性，哪怕初值为
null、undefined或默认值 - 避免
delete；逻辑删除改用字段标记，如isDeleted: true - 服务端返回数据若字段缺失，客户端做兜底填充（如
user.avatar = user.avatar ?? ''），防止同构对象分裂隐藏类 - 对结构高度不确定的数据（如用户自定义配置），改用
Map，明确告诉引擎“此处不走隐藏类优化路径”
验证是否踩坑：关注 IC 状态而非“异步”上下文
V8 不关心你是不是在 async 函数里读 obj.x，只关心此刻 obj 的隐藏类是否稳定、该访问点是否已进入 monomorphic（单态）状态。可通过以下方式观察：
- 开发期启用：
node --trace-ic script.js查看内联缓存状态（monomorphic / polymorphic / megamorphic） - 使用
%HasFastProperties(obj)（需开启--allow-natives-syntax）确认对象是否处于快属性模式 - 性能分析时重点关注“Property Load”耗时突增，结合堆快照比对对象隐藏类分布
