Python字典在对象模型中的关键作用

Python字典（尤其是实例的`__dict__`）并非语法糖，而是CPython对象模型中真实存在的哈希表，直接承载着绝大多数用户自定义对象的属性存储、动态增删能力与访问性能；它深刻影响着`__slots__`的内存优化效果、描述符协议的实际行为、内置类型与C扩展对象的兼容性，甚至决定pickle序列化和调试排查的成败——理解`__dict__`的本质，就是揭开Python对象状态管理的核心机制。

Python 对象底层其实共享一个 __dict__

几乎所有用户自定义类的实例，其属性存储都靠一个叫 __dict__ 的普通 dict 对象。它不是语法糖，是 CPython 对象模型里真实存在的哈希表——你每次写 obj.x = 1，本质就是往这个 __dict__ 里塞键值对。

这意味着：__dict__ 直接决定对象能否动态增删属性、是否支持任意键名、有没有属性访问开销。

• 没定义 __slots__ 的类，每个实例都有独立的 __dict__，内存占用高但灵活
• 用了 __slots__ 的类，实例不再有 __dict__（除非显式声明），属性名被硬编码进结构体，查属性快、省内存，但不能 obj.new_attr = ...
• __dict__ 是可读可写的字典，你可以直接修改它：obj.__dict__['x'] = 99，效果等同于 obj.x = 99，但绕过了 __setattr__

为什么有时候 __dict__ 是空的或根本不存在

常见错误现象：AttributeError: 'SomeClass' object has no attribute '__dict__' 或打印出来是空 {}，但属性明明能访问。

原因很实际：要么类用了 __slots__ 且没把 '__dict__' 加进去，要么对象是内置类型（如 int、list）或用 C 扩展写的类（比如 namedtuple 实例），它们压根不走 Python 层的字典机制。

• 检查方式：用 hasattr(obj, '__dict__')，别直接访问
• 想强制让 __slots__ 类支持动态属性？在 __slots__ 元组里加上 '__dict__'，例如 __slots__ = ('x', 'y', '__dict__')
• types.SimpleNamespace 这种“伪对象”倒是有 __dict__，但它只是个带字典的壳，和真正类实例的语义不同

dict 在描述符协议里的角色容易被忽略

当你定义了 @property、__get__ 描述符，或者用了 dataclasses.field，这些特性背后依然依赖 __dict__ ——只不过控制权交给了描述符逻辑。真正的数据可能藏在 __dict__ 里（如 _x），也可能存在别的地方（如闭包、弱引用缓存）。

• 描述符本身是类属性，存在类的 __dict__ 中；而它管理的实例数据，通常还是落在实例的 __dict__ 里
• 如果描述符是 non-data descriptor（只实现 __get__），而实例 __dict__ 里恰好有同名 key，那会优先取字典里的值，跳过描述符
• 所以不要假设 “用了 @property 就不会进 __dict__”，得看具体实现——比如 dataclass 默认就把字段值塞进 __dict__

改 __dict__ 不等于改对象状态的全部

有些对象的状态根本不存 __dict__ 里，比如：threading.Lock 的底层锁状态、re.Pattern 编译后的字节码、numpy.ndarray 的 buffer 指针。这时候改 __dict__ 只是动了个空壳。

• 判断依据：看类文档是否注明 “state is stored in C struct” 或类似描述
• 调试时别只盯着 obj.__dict__ 看，配合 vars(obj)（安全版 __dict__）和 dir(obj)，再查源码确认关键字段归属
• 序列化（如 pickle）默认靠 __dict__，所以自定义 __reduce__ 或 __getstate__ 才能正确保存 C 层状态

真正难的不是知道 __dict__ 存在哪，而是搞清某个具体类的设计者到底把什么放了进去、什么绕过去了——这得看源码，不是靠猜。

本篇关于《Python字典在对象模型中的关键作用》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！