“单态异步属性”并非真实概念，而是对单态性与异步执行的错误组合；异步操作不影响隐藏类匹配与内联缓存决策，属性访问形态仅取决于对象结构稳定性与IC site处的实际类型。
“单态异步属性”并不是一个真实存在的编译器概念，V8、Python JIT 或其他主流 JIT 引擎中均无此术语。它属于对两个独立机制（单态性、异步执行）的误组合，容易引发对底层优化逻辑的根本性误解。
异步本身不改变属性访问的形态
await 或 Promise.then 只影响代码何时执行、在哪条线程/任务队列中恢复，完全不参与对象结构判定、隐藏类匹配或内联缓存（IC）决策。
比如以下两段代码，在 V8 中产生的属性访问行为完全一致：
// 同步路径
function syncRead(obj) { return obj.x; }
// 异步路径
async function asyncRead(obj) { await Promise.resolve(); return obj.x; }
只要 obj 始终是同一隐藏类（如 {x: 1}），两次调用都会命中单态 IC；若 obj 类型混杂（如有时是 {x:1}，有时是 {x:1, y:2}），则无论同步异步，都会退化为多态甚至巨态。
真正决定隐藏类搜索与缓存效果的，只有对象创建和使用方式
- ✅ 稳定：所有实例在构造时就声明全部字段，顺序一致
class User { constructor(id, name) { this.id = id; this.name = name; } } - ❌ 不稳定：动态添加、删除、重赋不同类型值
const u = {}; u.id = 1; u.name = 'A'; delete u.name; u.name = null;
隐藏类缓存策略始终围绕“访问点（IC site）”展开，与调用栈无关
每个 obj.x 出现在源码中的位置，就是一个 IC site。引擎会为该 site 记录：
- 最近一次命中的隐藏类（monomorphic 缓存）
- 若连续遇到第 2 种隐藏类，则升级为 polymorphic 缓存（带小哈希表）
- 若超过 4 种，则标记为 megamorphic，直接跳过缓存，走慢路径
这个过程发生在属性读取瞬间，由对象当前内存布局实时触发，不感知函数是否被 async 修饰、是否在 microtask 中执行、是否跨 await 暂停。
你可以这样验证实际状态
在 Chrome DevTools 控制台中运行：
function test(o) { return o.x; }
%OptimizeFunctionOnNextCall(test);
test({x: 1});
console.log(%GetOptimizationStatus(test)); // 查看是否进入 monomorphic
再传入不同结构对象，观察状态是否降级——结果与是否加 async 完全无关。
本质上，所谓“单态异步属性”的优化问题，其实是把关注点放错了地方。重点从来不是“怎么让异步代码更快”，而是“如何让对象从诞生起就具备可预测的内存形状”。
