避开 Dataclass 的“经典大坑”：深入理解 field 中的 default 与 default_factory
摘要：本文深入解析 Python dataclass 中
field()函数的default与default_factory参数的核心区别与使用陷阱。通过对比分析，揭示default在类定义时一次性求值（“现成的”），而default_factory在每次实例化时动态计算（“现做的”）的本质差异。重点探讨两个经典坑：1）可变对象（list/dict/set）共享问题；2）环境变量读取时机导致的配置加载陷阱。最后提供清晰的使用场景指南，帮助开发者避免在实际项目中踩坑。
max_concurrent_files:int=field(default=get_env_value("MAX_CONCURRENT_FILES",1,int))"""Maximum number of files to process concurrently."""# 同时最多处理多少文件supported_file_extensions:List[str]=field(default_factory=lambda:[x.strip()forxinget_env_value("SUPPORTED_FILE_EXTENSIONS",".pdf,.jpg,.jpeg,.png,.bmp,.tiff,.tif,.gif,.webp,.doc,.docx,.ppt,.pptx,.xls,.xlsx,.txt,.md",str,).split(",")# 环境变量里只能存字符串，所以"列表型配置"就用逗号分隔的字符串存，读出来再切分])"""List of supported file extensions for batch processing."""# 可处理的文件类型上面是raganything的一段源码（中文注释，仅供参考），这里涉及到了python装饰器@dataclass中的一个“经典的坑”:field中的default与default_factory，我们今天就来看看这两个参数的具体区别
核心认知
在dataclass的field()中，这两个参数有着本质的区别：
default：接收一个具体的值（如1、“abc”）。在类定义阶段直接求值，把求值结果作为字段默认值，可以理解为：现成的值，一次性算好。default_factory：接收一个可调用对象（Callable，如函数、lambda、类名）。不立刻执行，只有每次实例化对象的时候才调用这个函数，将返回结果作为默认值，可以理解为：现做的值，每次新建对象重新计算。
简单来说，两者的核心区别在于：“这个东西是现成的，还是现做的”，如果不太明白这句话，不用着急，看完后面的讲解，你会理解的
坑一：可变对象的共享
Python 普通类中，如果默认参数是可变对象（list/dict/set），所有实例会共享同一个对象，修改一个实例会污染其他实例。（在我之前关于python参数传递机制那篇文章中有详细的讲解）
错误示范：
classWrong:def__init__(self,items=[]):self.items=items a=Wrong()b=Wrong()a.items.append(1)print(a.items)# [1]print(b.items)# [1]，被污染！print(id(a.items),id(b.items))# 同一个内存地址而在@dataclass中，直接写可变默认值会直接抛异常，提前阻止这个 bug：
fromdataclassesimportdataclass,field@dataclassclassWrong:items:list=[]# 错误示范：默认参数是可变对象a=Wrong()b=Wrong()a.items.append(1)print(a.items)print(f"实例a的items地址:{id(a.items)}")print(f"实例b的items地址:{id(b.items)}")""" 在 dataclass 里，可变默认值会在类定义时被直接拦截并报错：ValueError: mutable default <class 'list'> for field items is not allowed: use default_factory； 补充：该检测仅在默认 `init=True` 生效；如果设置 `init=False`，dataclass 不再做校验，依旧会出现对象共享 bug。 """items: list = []这行代码的后果：所有的实例共享同一个list对象。a.items.append(1)会影响到b.items。这就是“现成的”
正确写法，使用default_factory：
@dataclassclassRight:items:list=field(default_factory=list)a=Right()b=Right()a.items.append(1)print(a.items)# [1]print(b.items)# []，互相独立保证每次创建一个Right实例时，都会生成一个全新的、独立的列表对象。这就是“现做的”
坑二：容易忽略：执行时机带来的环境变量读取陷阱
回到开篇的配置代码，同样调用get_env_value()，两者执行时机完全不同。
字段：max_concurrent_files****，default：类定义时执行（模块导入瞬间）
default=get_env_value("MAX_CONCURRENT_FILES",1,int)- 执行时机：模块导入、类加载的时候
- 结果：
get_env_value在程序启动时只执行一次，返回值（比如5）被硬编码进类的默认值里。 - 隐患：如果你的程序运行后，动态修改了系统环境变量，或者这个配置依赖于运行时才生成的
.env文件，那么这个字段永远不会更新，它死死记住了启动时的值。 - 实战坑：dotenv 加载时序问题
# main.pyfromconfigimportProcessorConfig# 导入瞬间，default里面get_env_value已经执行完毕！fromdotenvimportload_dotenv load_dotenv()# 后加载.env，已经晚了，拿不到.env中的配置！cfg=ProcessorConfig()此时max_concurrent_files永远只能拿到代码写死的回退值，读不到.env里配置。
两种解决方案：
- 先 load_dotenv，再 import 配置类；
- 改用
default_factory，实例化阶段再读取环境变量。
字段 ：supported_file_extensions，default_factory：每次实例化才执行
default_factory=lambda:[x.strip()forxinget_env_value("SUPPORTED_FILE_EXTENSIONS","...",str).split(",")]- 执行时机：每一次实例化对象时执行一次
- 结果：
get_env_value在每次创建对象时都会被重新调用。 - 优势：假如你在程序运行中间修改了环境变量，或者这个变量依赖于当前进程的上下文，那么每次新实例都能拿到最新的值。
- 代价：频繁实例化对象时，会重复读取环境变量、重复字符串处理，带来额外开销。如果每秒创建大量配置对象，会有性能损耗。
小结
| 参数 | 接收类型 | 执行时机 | 使用场景 |
|---|---|---|---|
default | 字面量、不可变对象（int/str/bool/tuple） | 类导入定义时，仅一次 | 静态不变配置；简单数字字符串；启动后不会变化的值 |
default_factory | 可调用对象（函数 /lambda） | 每次实例化对象 | list/dict/set 可变容器；需要运行时动态计算；需要感知运行时环境变化 |
