dependency injector虽非必需，但它是大型项目最省心的依赖管理方案；硬编码实例化会锁死实现、阻断测试、拖慢迭代，须尽早改为构造函数注入，并用容器统一管理跨层依赖链。
Dependency Injector 不是必须的，但它是大型项目里最省心的依赖管理方案。硬编码实例化（比如 self.db = Database()）会直接锁死实现、阻断测试、拖慢迭代——这事必须改，而且越早改越轻松。
识别并清理硬编码依赖的常见位置
别指望 grep 一次扫完，重点盯三类代码：
• 数据库连接初始化：搜索 Database()、PostgresClient()、MySQLConnection() 等构造调用
• 外部服务客户端：如 HTTPXClient()、S3Client()、Redis()
• 配置加载逻辑：出现 os.environ.get("DB_URL") 或 json.load(open("config.json")) 的地方，尤其在模块顶层或 __init__.py 里
这些不是“配置”，是耦合点。它们一旦散落在各处，替换数据库或切环境时就得全局搜替换，极易漏、极易错。
构造函数注入是最小成本的起步方式
不用框架也能立刻解耦，核心就一条：把 __init__ 里的 new 操作全删掉，改成参数接收。
• 原来这样写：class OrderService: def __init__(self): self.db = Database("prod-url")
• 改成这样：class OrderService: def __init__(self, db): self.db = db
• 调用方负责传入：db = Database(config.database_url) → service = OrderService(db)
注意：类型注解 db: Database 不是装饰，是契约。它让 IDE 能提示、让 mypy 能检查、也让后续替换成 MockDatabase 时不会出 runtime error。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
用 dependency-injector 管理跨层依赖链
当项目超过 5 个服务、涉及 3 层以上调用（比如 API → Service → Repository → DB），手动传参会迅速失控。
• 容器定义要覆盖全部依赖生命周期：providers.Singleton 用于 DB 连接池、providers.Factory 用于每次请求新建的 RequestContext
• 配置必须走 providers.Configuration()，而不是在容器里写死 "localhost:5432"
• 所有服务类不 import 具体实现，只声明类型；容器负责把 PostgresRepo 绑定到 RepoInterface
• FastAPI 用户直接用 Depends(container.service)，不要自己 new；CLI 工具用 container.init_resources() 触发初始化。
Pydantic 字段级依赖容易被误用
Field(default_factory=...) 看起来像依赖注入，但它本质是默认值生成逻辑，不是运行时注入点。
• 错误用法：class Config(BaseModel): db_url: str = Field(default_factory=lambda: os.getenv("DB_URL")) —— 这仍是硬编码，且延迟到模型实例化才读环境变量
• 正确做法：把 Config 当纯数据模型，由容器或启动脚本加载后作为参数传入服务类
• 字段依赖只适合无副作用的轻量对象，比如 datetime.now 或 uuid.uuid4；重资源（DB、HTTP client）绝不能塞进 default_factory
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
