编译期依赖注入通过模板全特化将依赖绑定到类型系统，未注册类型在编译时报错而非运行时崩溃；其核心是显式特化injector模板，用静态成员函数resolve()返回单例或瞬态实例，依赖关系和生命周期均由编译器验证，但牺牲动态切换与跨模块灵活性。
编译期依赖注入在 C++ 里不是“自动扫描+反射注入”，而是靠模板特化把依赖关系固化到类型系统中——注册即编译，解析即实例化，没注册的类型根本通不过编译。
为什么 std::shared_ptr + std::unordered_map 的运行时容器不适用于编译期 DI
运行时容器（如用 std::type_index 做键）本质是手动管理的字典，resolve 失败只会在运行时报空指针或抛异常；而编译期 DI 的目标是让“未注册”变成编译错误。一旦你写了 container.resolve<ilogger>()</ilogger> 却没注册任何 ILogger 实现，它必须在编译阶段就报错，而不是等到 main() 执行时才发现。
- 运行时容器无法阻止你传入未注册类型，
resolve<t>()</t>可能返回nullptr，调用方要自己判空 - 模板参数推导不参与 SFINAE 的场景下（比如工厂函数返回类型硬编码），错误信息晦涩难懂
- 单例生命周期依赖顺序无法在编译期验证：A 依赖 B，B 依赖 C，但注册顺序错乱会导致构造/析构 UB
用全特化实现接口到实现类的编译期绑定
核心不是写个“容器类”，而是定义一个可特化的模板，让每个接口-实现对都成为一次显式特化。编译器会根据模板实参精确匹配，不匹配就报错。
例如定义一个可被特化的 injector 模板：
立即学习“C++免费学习笔记（深入）”；
template<typename Interface>
struct injector;
// 全特化：明确告诉编译器 ILogger 接口由 ConsoleLogger 实现
template<>
struct injector<ILogger> {
static std::shared_ptr<ILogger> resolve() {
return std::make_shared<ConsoleLogger>();
}
};
- 全特化必须写在全局命名空间，且
template尖括号不能省——漏掉就变成普通类，链接时找不到符号 - 不能对函数模板做全特化（C++ 标准禁止），所以
injector::resolve()必须是静态成员函数，不是自由函数 - 若需多实现切换（如测试用 MockLogger），直接新增另一个全特化：
template struct injector<ilogger> { ... MockLogger ... };</ilogger>，靠编译单元隔离或宏控制
如何让编译期 DI 支持 singleton / transient 生命周期
生命周期不是靠运行时标记（如 register_singleton<t>()</t>），而是靠特化内部的静态变量或局部静态对象来控制构造次数。
- singleton：在
resolve()中用局部静态std::shared_ptr，首次调用构造，后续直接返回 - transient：每次调用都 new 或 make_shared，不缓存
- scoped（如 per-thread）：需配合
thread_local静态变量，但要注意线程首次访问时机
示例 singleton 版本：
template<>
struct injector<ILogger> {
static std::shared_ptr<ILogger> resolve() {
static auto instance = std::make_shared<ConsoleLogger>();
return instance;
}
};
注意：这里 instance 是函数局部静态，线程安全（C++11 起），且析构顺序与该函数首次调用所在线程的 main() 结束顺序绑定——不是全局对象，避免静态初始化顺序问题。
编译期 DI 最容易被忽略的约束点
它不解决“谁创建谁”，而是把“创建逻辑是否完备”提前到编译阶段验证。真正棘手的是跨模块可见性与 ODR（One Definition Rule）。
- 全特化必须在所有使用
injector<ilogger>::resolve()</ilogger>的 TU（translation unit）中可见——通常得放在头文件里，且不能被多次定义；否则链接失败或行为未定义 - 若两个静态库各自特化了同一个
injector<ilogger></ilogger>，程序违反 ODR，但编译器不一定报错，运行时可能用错实现 - 无法动态切换实现：编译后
injector<ilogger></ilogger>绑定的就是那个特化版本，做不到运行时读配置换日志器
换句话说，编译期 DI 不是更“高级”的运行时容器替代品，而是另一条路：用编译错误换掉运行时不确定性，代价是灵活性归零。选它，就得接受“改实现=重编译+全量测试”。
