编译期依赖注入不能用 std::map 或 std::unordered_map，因其为运行时容器，键值对在编译期不可知，无法参与模板实例化和 constexpr 计算；必须基于类型而非字符串或 typeid()，后者在 constexpr 中不可用。
编译期依赖注入为什么不能用 std::map 或 std::unordered_map
因为它们是运行时容器，键值对在编译期不可知，无法参与模板实例化和 constexpr 计算。依赖注入容器若想在编译期完成类型绑定与解析，必须完全基于类型而非字符串或 typeid() —— 后者在 constexpr 上下文中不可用（typeid 非字面量类型，std::type_info::name() 更不可 constexpr）。
实操建议：
- 用
std::tuple存储所有已注册的类型实例（要求类型可默认构造或提供构造参数） - 用
std::index_sequence配合折叠表达式遍历 tuple，实现编译期线性查找 - 避免使用
std::any或std::variant，它们引入运行时开销且破坏编译期可推导性 - 注册表本身应为模板参数包展开的结果，而非运行时可变结构
如何通过模板参数包自动推导依赖关系
核心在于把“依赖”变成函数签名的一部分：构造函数参数类型即依赖声明。例如 class ServiceA { explicit ServiceA(ServiceB& b, Logger& l); }; —— 这里 ServiceB 和 Logger 就是编译期可提取的依赖类型。
实操建议：
- 用
decltype(&T::T)提取构造函数类型，再用std::function模板参数技巧（如template）解包参数包struct ctor_traits - 依赖图构建必须发生在类定义之后、容器实例化之前，因此注册需显式调用
container.bind等接口，不能靠 ADL 或宏自动发现() - 若某依赖未注册，编译错误会出现在 tuple 查找处（如
std::get失败），错误信息较晦涩；建议配合(tuple) static_assert+is_in_tuple_v提前报错
类型擦除与静态存储的取舍：为什么不用 void* 或 std::any
一旦引入 void* 或 std::any，你就放弃了编译期类型安全——无法做 static_cast 校验，无法参与 SFINAE，也无法让编译器优化掉未使用的绑定项。真正的编译期容器必须让每个绑定类型保留在模板参数中。
实操建议：
- 用
std::tuple<:unique_ptr>...>存储实例指针（支持多态但不丢失类型） - 或更轻量地用
std::tuple直接存储对象（要求所有类型可默认构造；若不可，默认构造 + 后续emplace可行，但需额外状态标记） - 禁止在容器内部出现
std::any、std::shared_ptr、std::function等运行时泛化机制 - 若需延迟初始化（如单例首次访问才构造），用
std::optional替代，它支持 constexpr 构造和 SFINAE 检测
constexpr 容器实例化失败的典型原因
即使所有类型都 trivially destructible 且有 constexpr 构造函数，constexpr container c; 仍可能失败——常见于 tuple 初始化顺序、未显式定义 constexpr 析构函数、或依赖了非 constexpr 的全局变量。
实操建议：
- 确保所有被绑定的类型满足
is_literal_type_v（C++17 起已弃用，改用is_trivially_destructible_v && is_default_constructible_v && has_constexpr_default_constructor） - tuple 成员初始化必须按声明顺序，若某类型构造依赖另一个尚未初始化的 tuple 元素，编译失败（无隐式依赖排序）
- 避免在构造函数体内调用非 constexpr 函数（如
std::cout、malloc、任何未标记constexpr的第三方函数） - 用
static_assert(std::is_constant_evaluated(), "not constexpr context");辅助调试
真正难的不是写出来，而是让整个依赖链上的每个类型都“愿意”被放进 constexpr 容器里——一个 std::string 成员就足以让整棵树退出编译期。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
