frozen=True仅冻结实例属性赋值，不阻止可变对象（如list、dict）的原地修改；嵌套dataclass不自动继承frozen；__post_init__是唯一可修改字段的合法时机，须用object.__setattr__；更新字段应使用replace()创建新实例。
为什么 frozen=True 不能阻止所有修改
因为 frozen 只冻结实例属性的赋值，不冻结可变对象内部状态。比如 list 或 dict 字段仍能被原地修改，dataclass 不会拦截 my_obj.items.append(1) 这类操作。
常见错误现象：AttributeError: can't set attribute 没出现，但数据却“悄悄变了”；调试时发现同一实例在不同位置输出不同内容。
- 使用场景：需要逻辑上不可变（如配置、缓存 key、hashable 结构），但字段类型选了
list或dict - 解决办法：用
tuple替代list，用frozenset或MappingProxyType封装字典 - 示例：
items: tuple[int, ...] = ()比items: list[int] = field(default_factory=list)更符合 frozen 意图
嵌套 dataclass 字段的 frozen 会传染吗
不会自动传染。父类设了 frozen=True，子类仍可自由修改——除非子类也显式声明 frozen=True。这是常见误解，导致以为“顶层冻结=全链冻结”。
容易踩的坑：父类 Config 冻结了，但其中字段 db: Database 是个非 frozen 的 dataclass，调用 config.db.host = "new" 依然成功。
立即学习“Python免费学习笔记（深入）”；
- 检查方式：用
hasattr(cls, '__dataclass_params__')和getattr(cls, '__dataclass_params__', {}).get('frozen', False) - 推荐做法：所有参与组合的 dataclass 都统一加
frozen=True，否则不可变契约就断在中间层 - 性能影响：嵌套 unfrozen 类不会拖慢父类创建，但会让整个结构失去 hashability 和语义一致性
__post_init__ 里还能改字段吗
可以，但仅限初始化阶段。frozen=True 的限制在 __post_init__ 执行完毕后才生效，所以这是唯一合法的“破冰窗口”。
使用场景：字段需依赖其他字段计算（如 full_name 基于 first + last），或做轻量校验/标准化（如把输入字符串转成 Path）。
- 注意：必须用
object.__setattr__(self, 'field', value)，直接写self.field = value会触发AttributeError - 错误示范：
self.cache = {}—— 即使用了object.__setattr__，若cache是可变容器，后续仍可被外部修改 - 兼容性：Python 3.7+ 行为一致，但 3.11+ 对
__post_init__中多次object.__setattr__的检查更严格
想让 frozen dataclass 支持字段更新怎么办
不能直接改，得换思路：用 replace() 创建新实例。这是标准且安全的做法，不是 workaround。
常见错误现象：试图绕过 frozen 用 vars(obj)['x'] = 1 或 type(obj).__dict__['x'].__set__(obj, 1)，结果破坏了 __hash__ 一致性或引发未定义行为。
- 正确姿势：
from dataclasses import replace; new_obj = replace(old_obj, x=42) - 参数差异：
replace不调用__post_init__，也不校验类型；若需校验，得自己封装一层工厂函数 - 性能提示：
replace是浅拷贝，嵌套可变对象（如list）仍共享引用；真要深更新，得配合copy.deepcopy或专用工具
最易被忽略的一点：replace 返回的是新对象，但很多人忘了重新赋值变量，还拿着旧引用继续用——这比 mutable 更难 debug。
