dataclass 的 default_factory 不支持依赖注入，因其要求无参可调用对象，而 DI 需运行时容器上下文；应改用延迟初始化、__post_init__（仅限容器已就绪）、或 factory 函数解耦构造与装配。
dataclass 的 default_factory 本身不支持依赖注入
default_factory 要求是一个**无参可调用对象**，Python 在实例化 dataclass 时直接执行它，不传入任何上下文或容器。所以你不能直接在里面写 container.resolve(MyService) —— 会报 TypeError: default_factory must be a callable taking no arguments。
这不是设计缺陷，而是 dataclass 的构造阶段早于 DI 容器的介入时机。dataclass 的 __init__ 是纯数据构造逻辑，而依赖注入属于运行时对象组装行为，二者天然错位。
绕过限制的常用做法：延迟初始化 + 手动注入
核心思路是：把真正需要依赖的对象从 field 中移出，改用属性（@property）或显式方法提供，并在外部完成注入。常见组合方式：
- 用
field(default=None)占位，配合init=False避免被纳入__init__参数，后续由 DI 容器或工厂函数手动赋值 - 定义一个
setup_dependencies(self, container)方法，在对象创建后调用，内部用container.resolve(...)补全字段 - 不继承 dataclass，改用普通类 +
@dataclass装饰器修饰部分字段（只装饰那些纯数据字段），其余依赖字段保留为普通实例变量
示例：
@dataclass
class OrderProcessor:
config: Config = field(default_factory=lambda: Config())
_service: MyService = field(default=None, init=False)
def setup_dependencies(self, container):
self._service = container.resolve(MyService)
用 __post_init__ 做轻量级注入（仅限容器已就绪场景）
如果 DI 容器是全局单例（如 injector 或自建 Container.get_instance()），且确保在 dataclass 实例化时已配置完毕，可以在 __post_init__ 中安全调用：
- 必须确认容器已初始化，否则会抛
LookupError或AttributeError - 不要在
__post_init__里做耗时操作（比如网络请求、DB 连接），dataclass 语义上不是初始化入口 - 避免循环依赖：若
MyService构造又依赖当前 dataclass 类型，会触发无限递归
示例（假设 get_container() 返回已配置好的容器）：
@dataclass
class ReportGenerator:
title: str
_renderer: Renderer = field(default=None, init=False)
def __post_init__(self):
self._renderer = get_container().resolve(Renderer)
更彻底的解法：放弃 dataclass 构造期注入，改用 factory 函数
真正解耦的方式是把 dataclass 当作“数据载体”，而把对象创建逻辑交给 factory。这样你能自由控制参数来源、顺序、条件分支，也兼容任意 DI 框架（injector、dependencies、python-dependency-injector 等）：
- factory 函数接收容器作为参数，先
resolve所需服务，再传给 dataclass 构造函数 - dataclass 字段全部声明为
init=True，不依赖default_factory - 可复用类型提示，IDE 依然能识别字段和类型
示例：
def make_order_processor(container) -> OrderProcessor:
return OrderProcessor(
config=container.resolve(Config),
service=container.resolve(MyService),
)
这种写法看起来多了一层，但实际更清晰、更可控——dataclass 不该承担运行时装配责任，那是 factory 或 DI 框架的事。
最易被忽略的一点：很多人试图给 default_factory 包一层闭包来“偷偷传参”，比如 lambda c=container: c.resolve(X)，但这只是把问题推迟到 runtime，且容易因闭包捕获的是旧容器引用而出错。真要注入，就得承认 dataclass 不是那个环节。
