编译期依赖注入在C++中通过模板参数和构造函数签名在编译时确定依赖关系，避免运行时容器的开销、调试困难与注册遗漏；真实项目采用组合根显式构建对象图，依赖解析即普通模板推导与函数调用，零运行时查找、无类型擦除、无RTTI依赖，且析构顺序可控。
编译期依赖注入在 C++ 里不是“用容器 resolve”，而是靠模板参数和构造函数签名让依赖关系在编译时就确定下来——没有运行时查找、不依赖 std::type_index 或字符串名，自然也就没循环依赖检测失败、类型擦除开销或 RTTI 不一致的问题。
为什么不用运行时容器注册/resolve？
硬套 .NET 风格的 container.register + container.resolve 在 C++ 里代价高、调试难、还容易漏注册。真实项目中更常见的是：启动时一次性构造整个对象图，所有依赖都在 main() 或组合根（Composition Root）里显式传入。这时候“注入”只是普通函数调用 + 模板推导，根本不需要运行时映射表。
-
std::shared_ptr容器缓存会隐式延长生命周期，导致析构顺序不可控（比如日志器在main返回后才析构） - 用
typeid(T).name()做 key 不跨平台，std::type_index虽好但仍是运行时机制，绕不开虚函数表查表开销 - 一旦注册分散在多个
.cpp文件，链接期才报错 “undefined reference to container::resolve”，定位成本远高于编译期报错
构造函数模板推导如何自动满足依赖？
核心是让编译器根据目标类型的构造函数签名，递归推导并实例化其所有依赖参数。不需要反射，只靠 std::make_shared 和可变参数模板就能完成。
- 假设
UserService构造函数是UserService(std::shared_ptr，那么, std::shared_ptr ) make_service就该自动调用(container) container.resolve和() container.resolve() - 关键限制：所有依赖类型必须在模板参数中可推导，不能是
int port这类非类型参数——得提前绑定，比如container.bind_constant(8080) - 不支持自动解析
std::unique_ptr或裸指针参数，因为所有权语义模糊；统一用std::shared_ptr或 const 引用更安全
接口注入 + 模板策略比运行时 DI 更轻量安全
很多所谓“需要 DI”的场景，其实只需要一个 std::function 或策略模板。比如 HTTP 客户端行为切换、重试策略、序列化格式，完全可以在编译期决定，零运行时开销。
- 写
class Processor比注册"retry_policy"字符串再resolve更快、更易内联、调试时直接跳转到 lambda 或具体策略类 - 接口注入（即构造时传
std::unique_ptr）已经足够解耦，mock 测试时直接传std::make_unique，无需容器参与() - 真正要警惕的是把
std::shared_ptr这种长生命周期对象也塞进模板推导链——它应该由组合根持有并按需传递，而不是让每个 service 都去“推导”一遍
最容易被忽略的边界：析构顺序与所有权归属
编译期注入不解决资源释放时机问题。如果 UserService 持有 std::shared_ptr，而 DatabaseConnection 析构时要发网络请求关连接，那它的生命周期就必须比 UserService 更长——这只能靠手动控制 shared_ptr 的创建位置（比如在 main 里先创建再传入），而不是依赖容器“自动管理”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
