C++编译期依赖注入只能通过模板元编程实现，无法用运行时框架；std::shared_ptr/unique_ptr因类型擦除破坏编译期推导性而不适用；真正可用的是具名类型、模板参数、constexpr值和别名模板。
编译期依赖注入在 C++ 里不能靠“框架”实现，只能靠模板元编程 + 类型推导 + 构造函数约束来模拟行为；它不解决运行时解耦，而是把依赖关系固化在类型系统里——用错场景反而增加编译负担和错误晦涩度。
为什么 std::shared_ptr 和 std::unique_ptr 不适合编译期注入
它们是运行时多态载体，类型擦除（如 std::any 或虚函数）会破坏编译期可推导性。真正能参与编译期依赖解析的只有具名类型、模板参数、constexpr 值和别名模板。
- 传
std::shared_ptr进模板函数？编译器看不到ILogger的具体实现，无法做 SFINAE 或requires约束 - 想让容器自动构造依赖链？必须显式写出每个类型的模板实参，比如
Container，否则无法推导构造顺序 - 依赖循环（A 依赖 B，B 依赖 A）在模板实例化阶段直接报错，但错误信息往往卡在
template instantiation depth exceeded，不是逻辑错误提示
用 auto + requires 实现最小可行注入契约
核心不是“注入”，而是“验证能否构造”。所有依赖必须通过构造函数签名暴露，且支持聚合初始化或默认构造。
template<typename t>
concept Injectable = requires {
typename T::inject_dependencies;
requires std::is_constructible_v<t typename t::inject_dependencies::type...>;
};
</t></typename>
-
T::inject_dependencies::type是一个std::tuple类型，列出 T 所需的所有依赖类型（如std::tuple） - 这个 tuple 必须在定义
T时静态写死，不能靠反射或宏生成——C++20 没有可靠字段反射 - 实际构造时用
std::make_from_tuple，但前提是所有依赖已作为变量存在且可绑定引用(deps_tuple)
手动组装依赖图比自动扫描更可控
没有“容器启动”概念，所谓“DI 容器”只是一个带状态的模板结构体，生命周期由作用域决定。
template<typename... services>
struct Injector {
std::tuple<services...> services;
template<typename t>
constexpr auto get() & {
if constexpr (std::is_same_v<t std::remove_cvref_t>(services))>>) {
return std::get<t>(services);
} else {
static_assert(sizeof(T) == 0, "T not registered in Injector");
}
}
};
</t></t></typename></services...></typename...>
- 注册即构造：
Injectorinj{LoggerImpl{}, DatabaseImpl{}}; - 获取即引用：
auto& logger = inj.get—— 不拷贝、不 new、无运行时查找(); - 不能动态增删服务：
Injector类型由模板参数完全决定，改一个依赖就得改整个类型名
最易被忽略的限制：跨编译单元依赖无法推导
如果 ServiceA 定义在 a.cpp，而 ServiceB 在 b.cpp 里需要它，那么 Injector 必须在同一个 TU（translation unit）里实例化，否则链接器看不到 ServiceA 的完整定义，模板无法完成实例化。
这意味着你没法把“DI 配置”单独抽成一个头文件然后到处 #include——它必须和具体服务的定义或使用点强耦合。一旦服务增多，Injector<...> 的模板参数列表会迅速失控，此时不如回归手动传参或用 struct Context { ServiceA& a; ServiceB& b; }; 显式传递。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
