|
|
这两年频繁用到 dataclasses，越用越觉得它不是“语法糖”，而是把数据建模这件事从“写代码”变成“表达意图”。很多人停留在替代 __init__ 的层面，实际上进阶玩法挺多，踩坑也不少。
先说 frozen 的误区。很多人以为 frozen=True 就是不可变对象，线程安全、高性能一把抓。事实并非如此。frozen 只是阻止属性在实例层面的再赋值，底层仍然是可变容器的话（比如 list、dict），你一样能改内容。要真不可变，得配合 tuple、MappingProxyType 或者用 types.MappingProxyType 包裹 dict；或者更简单，选择 attrs、pydantic 这种能限制更严的库。当然，dataclasses 本身也提供 slots=True，能显著降低内存占用、加快属性访问，但和 frozen 叠加的时候，某些场景（比如继承树较深）可能让调试变得麻烦。
其次是 default 与 default_factory 的边界。默认值里放可变对象是经典雷区：field(default_factory=list) 基本是肌肉记忆了。但真正的进阶是把 default_factory 用作“延迟构造策略”，比如根据环境变量、配置中心返回不同策略对象。这个时候要注意：factory 只在实例化时调用一次，不是属性级的惰性求值；若需要更细粒度的懒加载，用 property 或 cached_property 更合适。
再谈 init=False 的妙用。常见做法是把某些派生字段标记为 init=False，然后在 __post_init__ 里计算。比如存一个规范化后的路径、预编译的正则、或者基于其他字段哈希出的 cache key。这里的坑是顺序：__post_init__ 在 dataclass 构造完之后调用，继承链
的调用顺序是从最底层类往上逐层调用，这意味着父类里依赖子类字段的计算，可能拿到的是未加工或默认状态。解决办法有两种：一是把依赖明确下沉到子类的 __post_init__，父类只做与自身字段相关的工作；二是利用 kw_only 和 init=False 的组合，把关键依赖字段做成仅关键字参数并由最底层类负责注入，避免“半成品”在父类流转。
比较少被提及的是 kw_only 的价值。Python 3.10 起，dataclasses.field 支持 kw_only=True，可以把某些参数强制为关键字传入，既提升可读性，又能避免参数位移导致的灾难。配合 slots=True 与 frozen=True，可以构出“结构化配置对象”，既稳定又高效，非常适合在服务启动阶段承载经常被传递的上下文配置。
关于比较与哈希。默认情况下，dataclass 的 eq 与 order 会基于字段顺序生成，容易“误导排序”。比如你有个 timestamp 和 priority 字段，默认排序可能先比 timestamp，实际你却想按 priority 排。此时应关闭 order=True，改为实现 sort_key 或 total_ordering 基于单一 key 的比较逻辑；或者更简单，在需要排序的地方传入 key 函数，不把排序语义写死在数据结构里。哈希也类似：若对象的“身份”只由部分字段决定，记得用 field(compare=False, hash=False) 排除无关字段，并显式实现 __hash__，否则缓存与集合行为会很诡异。
再来是 metadata 的“灰度地带”。field(metadata={...}) 常被忽视，但在做通用序列化、OpenAPI 映射、权限标注时非常有用。你可以在 metadata 里放校验标签、序列化别名、敏感级别，然后写一层工具函数统一消费。配合 asdict 的 dict_factory，可以实现“带策略”的导出，比如忽略敏感字段、打平嵌套结构或改键名，避免在业务层写一堆 if-else。
继承与组合的拉扯也值得一提。dataclasses 支持继承，但我更倾向于组合优先：把可复用的字段组封装成小 dataclass，通过嵌套来复用，辅以 __post_init__ 做跨对象校验。这样比多层继承更清爽，也更便于局部演进。如果必须多重继承，注意 MRO 对 __post_init__ 的影响，最好在每层都显式调用 super().__post_init__()，并确保所有父类都遵循同一约定。
类型与运行时校验是另外一个现实问题。dataclasses 不做运行
时类型检查，你标了 List[int] 也不会帮你拦截传入的 str。我的做法有三种层次：开发期用 mypy/pyright 把静态问题尽量堵住；运行期在关键边界（比如外部输入、配置解析）手动做轻量校验；需要强约束时，用 dataclasses + 自写验证装饰器，或干脆引入 pydantic/attrs 负责校验与转换。别指望在核心路径里“既要性能又要强校验”，把验证放在系统边缘往往更划算。
序列化/反序列化是另一个坑点
序列化/反序列化是另一个坑点。asdict 很方便，但它是深拷贝、递归展开的，会把嵌套 dataclass 都转成普通 dict，丢失类型信息，也可能在大对象上造成性能压力。反向 from dict 则没有官方标准实现，自己写时要处理几件事：可选字段的缺省、Union/Literal 的分支、datetime/Decimal 等“半结构化”类型，以及版本迁移（老数据缺新字段）。实践里我更推荐两层方案：数据类只承载业务语义；I/O 层用明确的 Schema 转换（比如手写 map、或 marshmallow/serde），同时在入口做版本升级与字段映射。这样一来，
数据类就不背负跨版本演进的历史包袱，Schema 也更容易做灰度兼容与统计埋点。顺手一提，asdict 的 dict_factory 可以自定义，例如只展开一层、或对 None、空容器做过滤，别在高并发路径无脑 deep copy。
还有两个“冷门但好用”的点。一个是 replace：dataclasses.replace(obj, field=x) 非常适合在不可变（或拟不可变）模式下做“带差异复制”，配合 frozen=True 写起来既安全又直观。另一个是 astuple/astuple 的对称使用，在需要稳定顺序快照（比如做签名、缓存 key）时比 asdict 更可控，但要记得字段顺序就是接口的一部分，变更需慎重。
性能方面，slots=True 基本是白捡的收益，但别忽视与动态赋值、猴子补丁的冲突。一旦用上 slots，就不要再期望随手加属性。大批量构造时，尽量让 default_factory 避免做重活；对需要频繁比较/哈希的对象，明确 __hash__ 与 equality 语义，减少无谓字段参与。实测里，一个合理 |
|
发表于 
微信公众号
官方抖音号