编译期依赖注入通过模板元编程实现类型组合，避免运行时开销；std::shared_ptr和工厂函数因类型擦除无法支持编译期解析；injector模板通过deps声明和递归展开静态构建依赖图，循环依赖靠编译错误暴露。
编译期依赖注入在 C++ 里不是靠运行时容器实现的，而是靠模板元编程把依赖关系“展开”成类型组合——这意味着你没法像 Spring 那样写 @Autowired，但能彻底避免虚函数调用、指针解引用和动态内存分配。
为什么 std::shared_ptr 和工厂函数不解决编译期问题
很多人一开始想用 std::shared_ptr<interface></interface> + 工厂函数注册依赖，结果发现：类型擦除发生在运行时，dynamic_cast 或 std::any 会引入间接跳转，模板实例化无法推导出完整依赖图。更关键的是，编译器根本看不到“哪个类依赖哪个接口的具体实现”，也就没法做内联或死代码消除。
- 工厂返回
std::unique_ptr<irepo></irepo>→ 实际类型信息丢失，无法参与 SFINAE 或constexpr判断 - 手动 new 出来再传入构造函数 → 依赖创建逻辑散落在各处，无法统一约束生命周期和构造顺序
- 用宏模拟注解（如
INJECT(MyService)）→ 宏不参与模板匹配，不能触发重载决议或requires检查
injector 模板如何静态解析依赖链
核心是把“依赖”变成模板参数列表，让编译器通过函数签名推导+类模板偏特化完成绑定。典型结构是：injector<servicea serviceb repoimpl></servicea> 表示它能提供 ServiceA 和 ServiceB，而它们的构造函数参数（如 RepoImpl）已在模板参数中声明。
- 每个服务类必须定义
using deps = type_list<dep1 dep2></dep1>，显式声明依赖项（不能靠反射自动提取） -
injector内部用递归别名模板展开deps，检查是否所有依赖都在其模板参数包中存在可构造的匹配项 - 构造时调用
make<t>()</t>，实际展开为T{make<dep1>(), make<dep2>()}</dep2></dep1>—— 所有 new/delete/alloc 全部省略，对象直接在栈上构造
示例片段：
template <typename... services>
struct injector {
template <typename t>
constexpr T make() const {
if constexpr (has_deps_v<t>) {
return T{ make<typename t::deps::head>(), make<typename t::deps::tail>() };
} else {
return T{};
}
}
};
</typename></typename></t></typename></typename...>
依赖循环检测只能靠编译错误，不是运行时报错
没有运行时拓扑排序，也没有依赖图缓存。如果 ServiceA 依赖 ServiceB，而 ServiceB 的 deps 又包含 ServiceA，编译器会在实例化 make<servicea></servicea> 时无限展开模板，最终触发 error: template instantiation depth exceeds maximum 或更常见的 error: no type named 'head' in 'type_list'（空列表取 head 失败）。
- 这不是 bug，是设计使然：C++ 没有原生循环依赖检测机制，靠类型系统“卡住”是最轻量的方式
- 真实项目中建议用
static_assert在deps定义处加守卫，比如static_assert(!std::is_same_v<t typename deps::head>, "circular dep detected")</t> - Clang 错误信息比 GCC 更清晰，能看到哪一层模板展开失败；启用
-ftemplate-backtrace-limit=0有助于定位
真正难的不是写出能编译的 injector，而是让每个服务类的 deps 正确反映其真实依赖边界——少写一个，编译失败；多写一个，可能引发不必要的模板膨胀或 ODR 违规。这要求团队对模块职责有非常明确的契约定义，而不是靠运行时调试去“试出来”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
