因为 attrs 支持字段级延迟默认值、更细粒度冻结控制、原生 __attrs_post_init__ 钩子，且兼容 python 3.5；dataclass 在 __post_init__ 中无法安全访问其他字段，字段控制语法也更冗长。
为什么不用 dataclass 而选 attrs
因为 attrs 在 Python 3.6+ 里能做 dataclass 做不了的事：比如字段级默认值延迟计算、更细粒度的冻结控制、原生支持 __attrs_post_init__ 钩子，且对旧版 Python（如 3.5）仍有支持。如果你项目还在用 3.5 或需要字段初始化后立刻校验/转换，attrs 是更稳的选择。
常见错误现象：dataclass 里写 field(default_factory=Lambda: []) 看似可行，但无法在 __post_init__ 中安全访问其他字段——而 attrs 的 __attrs_post_init__ 总能拿到完整实例状态。
-
attrs默认不生成__init__的字段（如attr.ib(init=False)），dataclass必须靠field(init=False)，语义一致但写法略冗 - 想让某个字段只参与比较不参与哈希？
eq=True, hash=False直接配，dataclass得靠field(compare=True, hash=False) -
attrs的convert和validator是声明式内建能力，不用手动塞进__post_init__
attr.ib 的常用参数组合怎么选
别一上来就全用默认值。字段行为差异主要来自这四个参数的搭配：
-
default=...：静态值，比如default=None；动态值必须用factory，比如factory=list（注意不是factory=lambda: []，后者每次调用都新建 lambda 对象） -
converter=...：接收原始输入并转成目标类型，比如converter=str或自定义函数，失败抛ValueError，它在validator之前执行 -
validator=...：只校验，不改值，比如attr.validators.instance_of(int)，多个校验器用attr.validators.and_(...)组合 -
kw_only=True：强制该字段只能用关键字传参，适合可选配置项，避免位置参数错位
性能影响：所有 converter / validator 都在实例化时同步执行，高频创建对象时要注意函数开销；validator 不触发属性访问，所以不会意外触发 descriptor 的 __get__。
立即学习“Python免费学习笔记（深入）”；
冻结对象后还能改字段吗
能，但得绕过保护机制——这不是 bug，是设计如此：frozen=True 只禁用常规赋值（obj.x = 1），不拦 Object.__setattr__(obj, 'x', 1)。所以“冻结”本质是防误改，不是绝对不可变。
容易踩的坑：
- 用了
frozen=True却在__attrs_post_init__里直接赋值字段，会报FrozenInstanceError；正确做法是先调object.__setattr__(self, 'x', value) - 继承自 frozen 类的子类，如果没显式写
frozen=True，子类实例反而可修改父类字段——冻结不自动继承 -
attrs的evolve()函数能安全复制并修改字段，比手动绕过__setattr__更推荐
和 Pydantic v2 混用时字段校验谁生效
如果你把 attrs 类当 Pydantic 的 model_config = {'arbitrary_types_allowed': True} 里的字段类型用，校验链是：Pydantic 先走自己的验证逻辑（比如 str 转换、@field_validator），再把结果传给 attrs 实例化——此时 attrs 的 converter 和 validator 仍会执行。
这意味着：
- 重复校验可能触发两次异常，堆栈难读；建议关闭 Pydantic 对该字段的校验（用
Field(validate_default=False)），交由attrs全权处理 -
attrs的converter返回值若类型不符 Pydantic 预期（比如返回int但字段注解是str），Pydantic 会再转一次，可能出错 - 最稳妥的做法：只用
attrs做数据容器，Pydantic 做 API 层入参解析，两者职责隔离
复杂点在于字段级生命周期控制——attrs 的钩子发生在对象构造完成瞬间，Pydantic 的钩子则穿插在解析各层之间，混用时顺序和上下文容易错乱。