单态访问是jit运行时观测到的稳定属性访问行为，依赖隐藏类（记录字段布局的轻量元数据）实现硬编码偏移直取；需对象结构完全一致，否则触发去优化。
单态访问不是语法特性，也不是你写出来的某种“模式”，而是 JIT 编译器在运行时观测到的**稳定访问行为**——一旦确认，它就绕过整个属性查找链，直接生成类似 C 结构体成员访问的机器指令。你无法靠加注解或改类声明“开启”它，只能让运行时行为满足条件。
什么是隐藏类（Hidden Class）及其在单态访问中的角色
隐藏类是 V8 等 JIT 引擎为对象动态生成的“类型快照”，记录字段名、顺序、偏移量及是否可枚举等信息。它不对应 Python 的 __class__ 或 C++ 的 vtable，而是一个轻量级元数据结构，用于快速判断两个对象是否具有完全一致的内存布局。
单态访问成立的前提是：对同一属性（如 obj.x）的连续多次访问，全部命中同一个隐藏类。此时 JIT 会把该隐藏类的字段偏移（比如 x 在实例内存中距起始地址 +24 字节）硬编码进生成的机器码。
- 若下一次访问的对象来自子类、或运行时动态添加了字段（
obj.y = 1），隐藏类变更 → 单态性被破坏 → 触发去优化（deoptimization） - 隐藏类变更不会立即报错，但会导致后续调用回落到慢路径（
_PyObject_GenericGetAttrWithDict或 V8 的GetPropertyStub） - Python 的
__slots__和 JS 的Object.freeze()只是提高隐藏类稳定的概率，不是保证
从字节码到机器码：单态访问的三步直译过程
JIT 不解析字符串 "x"、不查哈希表、不走 PyObject_GetAttr，而是把 LOAD_ATTR 字节码直接编译为三条原生指令：
-
对象地址提取：将
obj的指针值载入寄存器（如 x86-64 下的rdi） -
字段偏移硬编码：用立即数加载固定偏移（如
movsd xmm0, [rdi + 24]），该数值来自当前隐藏类的 layout 缓存 -
零分支跳转：无
cmp+jne判断、无 fallback 跳转表 —— 仅当守卫失败时才插入守卫指令
这和 C 中 ((Point*)obj)->x 几乎等价。区别在于：C 是编译期确定，JIT 是运行时首次观测+守卫验证后确定。
类型守卫与布局守卫：单态性的实时验证机制
生成的机器码并非一劳永逸。JIT 在入口插入两条轻量守卫指令，每次调用都做快速校验：
-
cmp rdi, &Point_Type：比对对象实际类型指针是否等于观测到的类型（类型守卫） -
cmp DWORD PTR [rdi + 16], 0：检查ob_type->tp_dictoffset是否仍为 0（即未启用字典）、tp_basicsize是否未变（布局守卫） - 任一守卫失败 → 当前代码段标记为失效 → 下次调用触发解释器重编译（可能降级为多态路径）
守卫本身只消耗 2–3 个 CPU 周期，远低于一次哈希查找（通常 20+ 周期）。但如果你频繁混用不同类型对象（哪怕只是 Point 和 PointSubclass），守卫几乎必败，单态优化形同虚设。
为什么手动干预往往适得其反
开发者常误以为加 __slots__、用 typing.cast、甚至强制类型断言就能“锁定”单态性。事实并非如此：
-
__slots__ = ('x',)只防止动态添加字段，但若第一次传Point、第二次传PointSubclass，隐藏类已不同 → 多态 -
typing.cast(Point, obj)对运行时无任何影响，JIT 完全无视类型注解 - 试图用
isinstance(obj, Point)提前判断？这本身就会引入分支，且守卫已比它更快更轻量
真正可控的只有两点：确保同一批逻辑中操作的对象来自同一类（非继承关系）、避免运行时增删属性。其余交给 JIT —— 它比你更清楚什么时候该硬编码、什么时候该退守。
