纯模板实现的编译期DI在C++中可行，但需依托类型系统与元编程，适用于嵌入式等编译时依赖完全已知场景，不适用于需运行时动态加载或配置的通用服务。
纯模板实现的编译期依赖注入（DI）在 C++ 中可行，但不等于“开箱即用”——它本质是类型系统与元编程的组合技，不是替代 std::shared_ptr 或工厂函数的运行时方案，而是为零成本抽象、强类型绑定和静态验证服务。
为什么不能直接套用 Spring 或 Autofac 的思路写 C++ 模板 DI
运行时 DI 框架依赖反射、字符串标识符、动态注册表和类型擦除；C++ 模板在编译期无类型名字符串、无运行时类型查询、无通用容器能存任意可调用对象。硬搬会导致：
-
std::any或std::function回退到运行时调度，失去编译期约束 - 试图用
constexpr std::string_view做服务名键，但无法用于非字面量场景（如模板参数推导出的服务名） - 过度依赖宏或复杂别名链，让错误信息变成 200 行模板展开堆栈
真正可行的路径是：用模板参数显式声明依赖，用 auto 或概念约束推导实现，靠编译器报错做“注入失败检测”。例如：
template<typename service>
struct Injector {
template<typename t>
constexpr auto inject() {
if constexpr (std::is_constructible_v<t service>) {
return T{service_};
} else {
static_assert(sizeof(T) == 0, "T cannot be constructed from Service");
}
}
private:
Service service_;
};</t></typename></typename>
requires 约束比 static_assert 更适合表达注入契约
用 static_assert 报错位置靠后，且不参与重载决议；而 requires 让不满足条件的模板实例直接从候选集中剔除，配合 SFINAE 可自然支持多策略 fallback。
- 错误信息更短：报错指向
requires子句，而非整个函数模板实例化栈 - 可组合：比如
requires Injectable&& DefaultConstructible - 避免“假成功”：没有
requires时，inject可能静默构造出错误类型的对象（如误用了隐式转换）()
典型用法：
template<typename t>
requires std::default_constructible<t> &&
requires(T t) { t.init(); }
constexpr auto create_service() { return T{}; }</t></typename>
编译期 DI 的真实适用边界：嵌入式、音视频处理管线、编译器插件
它不是通用 Web 服务的替代品，而是当以下条件同时成立时才值得投入：
- 所有依赖关系在编译时完全已知（无插件热加载、无配置驱动模块加载）
- 对二进制体积和启动延迟极度敏感（如车载控制器固件）
- 需要编译器保证“某个服务未被注入则编译失败”，而非运行时报
"Service X not found" - 团队熟悉
concepts、if constexpr和 CTAD，能读懂error: no type named 'type' in 'struct std::enable_if'
常见误用：给 HTTP 路由器加模板 DI，结果每个路由 handler 都生成一份独立实例，导致代码膨胀；或强行把数据库连接池塞进模板参数，忽略连接建立必须发生在运行时。
最简可用原型只需三样东西：injector、bind、get
不必一开始就设计“模块”“作用域”“生命周期管理”。先跑通最小闭环：
-
injector是一个空结构体模板，仅携带类型列表：templatestruct injector {}; -
bind是一个别名模板，把接口与实现绑定：templateusing bind = impl::concrete ; -
get是一个 constexpr 函数，通过decltype和requires查找并构造：templateconstexpr auto get(injector ) { ... }
此时你已经能写出：
struct Logger { void log(const char*) {} };
struct App { App(Logger l) : logger{l} {} Logger logger; };
auto i = injector<logger>{};
auto app = get<app>(i); // 编译期推导 Logger 构造 App</app></logger>
再往后加“单例缓存”或“作用域嵌套”，就不再是编译期问题，而是得引入 thread_local 或静态变量——那已经是混合模型了。
真正难的不是写出来，而是守住编译期边界：一旦开始为“方便调试”加运行时日志、为“兼容旧代码”加 void* 回调、为“配置灵活”加 JSON 解析，这个系统就已在坍缩。它只对绝对确定的依赖图有效，多一分不确定，就多一分维护成本。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
