在 Python 的面向对象编程中，@dataclass 装饰器极大地简化了数据类的定义，帮我们自动生成了 __init__、__repr__ 和 __eq__ 等样板代码。然而，在处理字段默认值时，许多开发者（甚至包括经验丰富的老手）都容易踩进一个经典的“可变默认参数”陷阱。本文将结合实战场景，深入剖析 field(default_factory=...) 的核心机制与最佳实践。
危险的共享：为什么不能直接写 tags: list[str] = []？
在 Python 中，函数的默认参数（包括 dataclass 自动生成的构造函数参数）如果是一个可变对象（如列表 [] 或字典 {}），它只会在类定义时被创建一次。这意味着所有未显式传参的实例，都会共享同一个底层对象。
假设我们这样定义用户档案类：
@dataclass
class UserProfile:
name: str
age: int
tags: list[str] = [] # ⚠️ 危险写法
当我们创建两个用户并修改其中一个的标签时，诡异的现象就会发生：
user1 = UserProfile("Alice", 25)
user2 = UserProfile("Bob", 30)
user1.tags.append("VIP")
print(user2.tags) # 输出: ['VIP'] 😱 Bob 莫名其妙也被加了 VIP！
因为 user1 和 user2 实际上共享了同一个列表引用。修改一个，另一个也会跟着变。这在工程实践中是极其危险的 Bug 来源。
破局之道：default_factory 的“按需生产”机制
为了彻底解决对象共享问题，dataclasses 模块提供了 field 函数。当我们使用 field(default_factory=list) 时，dataclass 接收的是一个无参可调用对象（如类名或函数），而不是一个已经实例化的对象。
@dataclass
class UserProfile:
name: str
age: int
tags: list[str] = field(default_factory=list) # ✅ 安全写法
在这种写法下，dataclass 会在每次创建新实例时，都去调用一次 list() 函数。创建 user1 时，生成一个全新的空列表；创建 user2 时，再生成另一个全新的空列表。每个实例都有自己独立的内存空间，互不干扰。简单来说，直接赋值是“所有人共用一个篮子”，而 default_factory 则是“给每个人发一个新篮子”。
认知纠偏：不可变类型需要 default_factory 吗？
理解了上述机制后，我们需要明确一个关键边界：default_factory 并非万能药，它主要用于解决“可变对象共享”和“动态计算”的问题。
对于不可变类型（如字符串 str、数字 int、元组 tuple），如果默认值是固定的，直接赋值才是最佳实践。例如：
created_at: str = "2024-01-01" # ✅ 完全正确，且最简洁
字符串是不可变的，不存在被意外修改的风险，因此无需使用 default_factory。
那么，什么时候不可变类型才需要用到 default_factory 呢？答案是：当这个值需要在每次实例化时动态生成时。最典型的场景就是记录创建时间：
from datetime import datetime
@dataclass
class UserProfile:
name: str
# ✅ 正确：每次创建用户时，动态调用 datetime.now() 获取当前时间
created_at: datetime = field(default_factory=datetime.now)
# ❌ 错误：如果在类定义时直接赋值，那么所有用户的创建时间都会变成
# 程序启动时的那一瞬间，而不是各自创建时的时间。
# created_at: datetime = datetime.now()
总结与最佳实践
在 dataclass 中设置默认值，请遵循以下三条黄金法则：
- 不可变且固定的值（如字符串
"2024-01-01"、数字0）：直接赋值= "2024-01-01"即可。 - 不可变但需要动态计算的值（如当前时间
datetime.now()）：必须使用default_factory=datetime.now。 - 可变对象（如列表
[]、字典{}）：必须使用default_factory=list或default_factory=dict，从根源上杜绝状态污染。
掌握这些细节，不仅能让你写出更 Pythonic 的代码，还能在复杂的业务逻辑中避免许多难以排查的隐蔽 Bug。