Python 3.11 的 __dict__ 查找变快，核心是重构属性查找路径、引入 LOAD_ATTR_INSTANCE 字节码及内联缓存，普通实例属性读取快10%–25%，但仅适用于未重载 __getattribute__ 的纯 Python 类，且受 __dict__ 赋值等条件影响缓存失效。
Python 3.11 的 __dict__ 查找为什么变快了
Python 3.11 对实例属性访问做了底层优化，核心是重构了属性查找路径，把原本需要多次哈希查找和字典遍历的操作，压缩成更少的指令跳转。关键改动在 CPython 解释器的 _PyObject_GenericGetAttrWithDict 路径中，跳过了部分冗余的 __getattribute__ 分发逻辑，并对空/小尺寸 __dict__ 做了内联缓存（inline cache）预热。
实际效果：普通实例属性读取（如 obj.x）在 3.11 中平均比 3.10 快 10%–25%，尤其在循环内高频访问时差异明显。但这个加速只作用于纯 Python 实例（即未自定义 __getattribute__ 或 __getattr__），一旦重载，缓存机制会退回到旧路径。
- 不生效场景：
__slots__类、C 扩展对象、带自定义__getattribute__的类 - 验证方式：用
timeit测obj.attr，对比 3.10 和 3.11，注意关闭 GC（gc.disable()）避免干扰 - 缓存不是全局持久的——每个类实例首次访问某属性时仍有一次“冷启动”开销，后续才命中 inline cache
LOAD_ATTR 字节码在 3.11 中的变更点
3.11 引入了新的字节码 LOAD_ATTR_INSTANCE 和 LOAD_ATTR_CLASS，替代了旧版统一的 LOAD_ATTR。解释器在首次执行时会根据对象类型动态选择路径：如果是普通实例且 __dict__ 存在，走更快的 instance 路径；如果是类对象或描述符，则走 class 路径。
这意味着你不需要改代码就能受益，但要注意：如果运行时动态修改了类结构（比如给类加了描述符或覆盖了 __getattribute__），已编译的函数可能仍沿用旧路径，直到重新编译（如 reload 模块或重新定义函数）。
立即学习“Python免费学习笔记（深入）”；
- 查看字节码：用
dis.dis(lambda: obj.x)，3.11 下能看到LOAD_ATTR_INSTANCE - 不兼容行为：某些字节码分析工具或 monkey patch 工具（如
bytecode库）若没适配新指令，会报错或跳过解析 - 性能敏感场景建议显式标注类型（
obj: MyObj），帮助解释器更早收敛到 instance 路径
为什么 getattr(obj, 'x') 没明显变快
getattr 是纯 Python 函数，它绕过了直接属性访问的 inline cache 机制，始终走通用查找逻辑（包括检查 __getattribute__、__dict__、MRO 链等）。所以即使底层 LOAD_ATTR 变快了，getattr 本身没做任何优化，实测 3.11 下性能与 3.10 基本一致。
- 如果你在循环里频繁调用
getattr(obj, name)，瓶颈不在解释器，而在字符串查找和函数调用开销 - 替代方案：提前用
operator.attrgetter('x')或闭包（lambda o: o.x）固化访问路径 - 错误认知：“用了 3.11 就不用管 getattr 性能了”——恰恰相反，这种动态访问模式反而更凸显其劣势
缓存失效的隐蔽条件
3.11 的 inline cache 不是万能的。只要触发以下任一条件，当前帧的属性访问就会降级为慢路径：
- 对象被设置过
__dict__（比如obj.__dict__ = {...}） - 类定义了
__slots__但实例又意外获得了__dict__（例如继承链中某父类没设__slots__） - 同一类下混用不同类型的实例（比如部分实例有额外属性，部分没有），导致缓存键无法复用
- C 扩展对象返回的实例（如 NumPy array、Pandas Series）不参与该缓存机制
最易忽略的是 __dict__ 赋值操作——哪怕只写一次，也会让后续所有同类型实例的该属性访问失去缓存收益。调试时可用 sys._getframe().f_lasti 配合字节码检查是否命中了 LOAD_ATTR_INSTANCE，比单纯看耗时更可靠。
