编译期依赖注入本质是类型构造与组合，非对象生命周期管理；std::shared_ptr和std::unique_ptr引入运行时开销、掩盖类型依赖，且无法在constexpr上下文中穿透推导构造约束，真正可行的是模板参数传递依赖+constexpr构造函数驱动的类型绑定。
编译期依赖注入在 C++ 里无法靠“模板系统”完整模拟运行时 DI 容器的行为——它本质是类型构造与组合问题，不是对象生命周期管理问题。
为什么 std::shared_ptr 和 std::unique_ptr 不适合编译期注入
编译期注入不涉及堆分配、引用计数或销毁顺序调度。用智能指针包裹类型只会引入运行时开销和生命周期语义污染，掩盖真正的类型依赖关系。
- 模板推导无法穿透
std::shared_ptr<t></t>获取T的构造约束（比如T是否有无参构造函数） -
std::unique_ptr移动语义在编译期无意义；其存在本身暗示“运行时所有权”，与 constexpr 上下文冲突 - DI 容器注册表（如 map
）无法在 constexpr 中构建
真正能落地的编译期“注入”只发生在类型层面：用 template 参数传递依赖
所谓“注入”，其实是把一个类型作为另一个类型的模板参数传入，让编译器在实例化时完成类型绑定。这不是“容器管理对象”，而是“类型组装”。
- 典型模式：
template<typename loggerimpl="NullLogger"> class Service { ... };</typename> - 依赖必须满足：可默认构造（或提供完整构造参数）、无虚析构要求（除非你明确需要多态擦除）
- 若需差异化配置，应通过策略类（
struct Config { static constexpr int timeout = 5000; };）而非运行时参数 - 避免在模板参数中塞入具体实现类名（如
FileLogger），优先用别名模板或 using 声明解耦
constexpr 构造函数 + 模板参数推导是唯一可靠的编译期服务组装方式
只有当所有依赖类型都支持 constexpr 构造，且构造过程不触发动态内存分配或未定义行为时，才能确保整个链路在编译期完成。
立即学习“C++免费学习笔记（深入）”；
- 错误示例：
std::string不能用于 constexpr 上下文（C++20 前），因此含std::string成员的类无法参与编译期注入 - 正确路径：用字面量字符串视图
std::string_view替代，或用const char[]静态数组 - 依赖链中任一环节缺失
constexpr构造函数（哪怕只是日志器里的一个std::time(nullptr)），整条链就退化为运行时构造 - Clang/GCC 对 constexpr 递归深度有限制，过深嵌套（如 10 层以上模板特化+constexpr 构造）可能触发
error: constexpr evaluation hit maximum step limit
实际工程中，“编译期依赖注入”往往只是部分类型绑定 + 部分运行时工厂的混合体。强行追求全链路 constexpr，容易让接口僵化、调试困难、错误信息晦涩——最常被忽略的，是把“编译期可计算”等同于“编译期已构造”。前者是能力，后者才是结果，中间隔着标准库实现细节、编译器优化开关和 ODR 使用规则。
