@dataclass 是类装饰器，非语法糖，类定义完成后调用 dataclass() 动态注入方法、生成 Field 实例并存入 __dataclass_fields__，按源码顺序处理字段，不修改 AST 或元类逻辑。
dataclass 是怎么被 Python 解释器识别的
Python 在 3.7 引入 @dataclass，它本身不是语法糖，而是一个**类装饰器**——也就是说，解释器遇到这个装饰器时，并不会改变语法解析过程，而是在类定义完成、但尚未返回类对象前，调用 dataclass() 函数对类进行就地改造。
关键点在于：它不修改 AST，也不影响 __new__ 或元类逻辑（除非你显式指定 metaclass），而是直接操作类的 __dict__ 和 __annotations__，动态注入方法（如 __init__、__repr__）和字段描述符。
-
@dataclass会检查类体中所有带注解的变量（包括field()调用），生成Field实例并存入__dataclass_fields__类属性 - 若未显式定义
__init__，它会在装饰后自动注入；但一旦你写了，就不会覆盖（除非设init=False） - 字段顺序严格按源码中出现顺序，而非字典插入顺序（CPython 3.7+ 保证类体执行顺序，所以可靠）
field() 的作用不只是设置默认值
field() 看似只是包装默认值，实际它控制字段在 dataclass 生命周期中的行为边界。它的返回值是 Field 对象，会被 dataclass() 提取并用于生成初始化逻辑、比较逻辑、序列化逻辑等。
常见误用是把可变对象（如 list）直接传给 default=，这会导致所有实例共享同一对象——必须用 default_factory=list。
立即学习“Python免费学习笔记（深入）”；
-
default：仅接受不可变值或None；default_factory才用于可变默认值 -
init=False表示该字段不参与__init__参数，但仍出现在__dataclass_fields__中，可用于运行时计算或缓存 -
compare=False或repr=False会分别从__eq__和__repr__中排除该字段，但字段本身仍存在且可访问
为什么继承 dataclass 类有时会出错
dataclass 的字段合并规则不是简单的“子类覆盖父类”，而是按 MRO 从底向上收集所有带注解的字段，再按首次出现顺序排序。问题常出在：父类用了 field(default=...)，子类又用同名变量但没加注解，或者子类加了注解却漏掉 field() 配置。
典型错误现象：TypeError: non-default argument 'x' follows default argument —— 这说明字段顺序混乱，Python 检查到某个有默认值的字段后面跟着无默认值字段。
- 所有字段必须显式注解，否则不会被识别为 dataclass 字段（哪怕用了
field()） - 如果父类是 dataclass，子类即使不加
@dataclass，也会被自动视为 dataclass（只要没定义__init__等冲突方法）；但显式加上更安全 - 多个父类都是 dataclass 时，字段顺序由 MRO 决定，但同名字段只保留第一个（来自最左侧父类），后续同名声明会被忽略
__post_init__ 不是构造函数的补充，而是初始化钩子
__post_init__ 在自动生成的 __init__ 执行完之后调用，它接收的是已赋值完毕的实例，而不是参数。很多人误以为它可以“重设”字段值并影响 __init__ 行为，其实不能——此时字段已经写入实例 __dict__，__post_init__ 只能做校验、转换或派生计算。
- 它不接收任何参数（除了
self），所有字段值都已通过__init__设置好了 - 如果字段设了
init=False，它不会出现在__init__参数中，但你在__post_init__里可以安全赋值（比如self._cache = []） - 注意：若父类和子类都有
__post_init__，子类必须显式调用super().__post_init__()，否则父类逻辑不会执行（这点和普通方法一致）
真正底层复杂的地方在于字段可见性与 descriptor 协议的交织——比如你给字段加了 property，dataclass 默认不会干涉，但如果你同时用 field(init=False) 和 @property，就得自己确保访问逻辑不冲突。这些细节往往在调试时才暴露出来。
