编译期依赖注入在 C++ 里不是靠框架“实现”的，而是靠模板元编程 + 类型系统“自然浮现”的——你写不出运行时容器、不注册服务、不反射，照样能达成解耦和可测试性。关键在于：用 std::type_identity 或空基类控制依赖绑定时机，用 requires 约束接口契约，用模板参数显式声明依赖。
为什么不用 std::function 或虚函数做“注入点”
虚函数调用有 vtable 查表开销，且无法在编译期验证实现是否满足接口；std::function 引入类型擦除和堆分配，破坏 constexpr 可行性。真正的编译期注入必须让依赖类型直接参与模板实例化过程：
- 所有依赖必须是完整类型（不能是前向声明）
- 接口需定义为概念（
concept），而非抽象基类 - 组合逻辑写在类模板参数列表里，而不是构造函数里
例如：template<typename logger typename db> class UserService</typename> —— 这一行就完成了“注入声明”，无需额外注册代码。
injector<t></t> 模板如何避免 ODR 和二义性
很多人试图写一个全局 injector 类模板来“解析”依赖树，结果遇到重复实例化或 SFINAE 失败。正确做法是放弃“自动解析”，改用显式组合：
立即学习“C++免费学习笔记（深入）”；
- 不提供
injector::create<service>()</service>这类泛型工厂 - 每个组合单元（如
App）自己 new 出全部依赖，并传给被组合者 - 用
[[no_unique_address]]成员压缩空依赖（比如无状态 logger） - 若需复用构造逻辑，封装为
make_service<t>(args...)</t>函数模板，而非单例容器
这样既规避了 ODR（每个 TU 自己实例化），也避免了依赖图环检测等元编程地狱。
真实项目中必须处理的三个硬约束
概念上干净 ≠ 工程上可用。以下三点不处理，代码进不了生产：
-
Logger接口可能需要运行时配置（如日志级别），但又要保持constexpr构造——解决方案：把配置项抽成独立模板参数，如template<log_level l> struct ConsoleLogger</log_level> - 某些依赖（如数据库连接池）必须单例且带生命周期管理——用
static inline变量 +std::shared_ptr，但确保该变量不参与任何模板参数推导链 - 测试时要替换依赖，但又不想改头文件——用
#ifdef TEST切换模板实参，或更稳妥地：在 CMake 中通过target_compile_definitions注入MOCK_DB宏
没有银弹。所谓“编译期注入”，本质是把依赖关系从运行时决策提前到模板参数选择阶段，而参数选得是否合理，取决于你对模块边界和变化原因的判断——这点，再强的模板也替代不了。
