依赖注入在Python中无需框架即可落地，构造函数注入最稳妥；真正难点在于依赖声明时机、生命周期管理及环境一致性，而非语法本身。
直接说结论：依赖注入在 Python 中不需要框架也能落地，但用不用框架取决于项目规模和团队习惯；真正卡住落地的不是语法，而是依赖声明时机、生命周期管理、以及测试与生产环境的一致性。
构造函数注入是最稳的起点
这是最贴近 Python 原生风格、也最容易被团队接受的方式。它不依赖任何库，靠参数显式传递依赖，调用链清晰，IDE 和类型检查器（如 mypy）能直接推导类型。
- 常见错误现象：
TypeError: __init__() missing 1 required positional argument: 'repo'—— 忘记传参，或测试时仍沿用旧写法OrderService()而非OrderService(MockRepo()) - 使用场景：服务类、处理器类、策略消费者（如
SignalProcessor）等有明确协作关系的对象 - 参数差异：不要混用可选参数和必需依赖，
def __init__(self, db, cache=None)容易让cache变成“半注入半硬编码”，建议全显式或全可选（用None+ 类型注解 + 初始化校验） - 性能影响：无额外开销，对象创建即完成依赖绑定
python-inject 的 bind() 绑定策略选错会引发隐性单例问题
python-inject 的核心是 bind()，但它三种绑定方式的行为差异极大，尤其容易在开发后期暴露问题。
- 实例绑定（
binder.bind(ConfigManager, ConfigManager())）：配置对象适合，但若绑的是带状态的连接池（如DBConnection），会导致所有请求共享同一连接，高并发下出错 - 构造函数绑定（
binder.bind_to_constructor(DBConnection, DBConnection)）：延迟初始化、单例，适合数据库连接、日志器等——但必须确保构造函数本身是幂等的 - 提供者绑定（
binder.bind_to_provider(RequestContext, lambda: RequestContext())）：每次injector.get()都新建实例，适合 request-scoped 对象；但如果 provider 函数里做了耗时操作（如读文件、连 Redis），性能会明显下降 - 容易踩的坑：在 FastAPI 中混用
python-inject和原生依赖（Depends），导致同一个类被初始化两次，状态不一致
FastAPI 的 Depends 不是“注入容器”，而是请求生命周期调度器
很多人误以为 Depends 是个轻量版 DI 容器，其实它只在每次 HTTP 请求进入时按需执行依赖函数，并缓存其返回值到该请求生命周期内。它不管理全局单例，也不跨请求共享状态。
立即学习“Python免费学习笔记（深入）”；
- 常见错误现象：
AttributeError: 'Request' object has no attribute 'db'—— 在依赖函数里试图从Request对象上取未挂载的属性，应改用request.state.db或显式传参 - 使用场景：鉴权中间件、数据库 session、当前用户信息、请求上下文配置等强绑定 request 生命周期的对象
- 性能影响：依赖函数内避免 IO 操作；若需复用已有连接（如 SQLAlchemy
Session），务必用yield实现 cleanup，否则连接泄漏 - 兼容性注意：不能直接把
injector.get(SomeService)塞进Depends()当参数，因为Depends期望的是可调用对象，不是实例
手动注入 + 类型注解 + pytest fixture 是中小项目最可控的组合
当项目还没到需要容器自动解析的程度，或者团队对 DI 框架学习成本敏感时，“手写 + 注解 + 测试驱动”反而更透明、更少意外。
- 示例结构：
class PaymentService: def process(self, amount: float) -> bool: ... <p>class OrderService: def <strong>init</strong>(self, payment: PaymentService): self.payment = payment</p><h1>tests/test_order.py</h1><p>def test_order_service_processes_payment(): mock_payment = Mock(spec=PaymentService) mock_payment.process.return_value = True service = OrderService(mock_payment) assert service.process_order(100.0) - 为什么这样做：类型注解（
payment: PaymentService）让 IDE 补全、mypy 检查、pytest fixture 注入都自然对齐；没有隐藏的绑定逻辑，新人看三分钟就能改测试 - 容易忽略的点：模块级常量（如
DEFAULT_TIMEOUT = 30）别硬写进类里，应作为依赖项注入，否则无法在测试中覆盖；否则你会在 CI 环境里发现超时设成了 30 秒，而本地 mock 却没生效
真正难的不是怎么写 bind() 或 Depends()，而是决定哪些东西该被注入、哪些不该——比如一个纯计算函数（def normalize(data: list) -> list）就不该有依赖，加了反而增加理解负担。边界模糊时，优先保持简单。
