编译期依赖注入通过模板特化将依赖固化到类型系统，注册即编译、未注册即编译失败；binding特化须定义在头文件中，不支持自动装配与生命周期管理，且易导致编译时间激增。
编译期依赖注入在 C++ 里不是“加个注解就自动注入”，而是靠模板特化把依赖关系固化到类型系统中——注册即编译，未注册即报错，没有运行时查找、没有 std::type_index 映射、也不依赖 std::function 工厂封装。
为什么 container.resolve<t>()</t> 在编译期就能失败
关键不是 resolve 函数本身，而是它背后用 static_assert 或 SFINAE 检查一个编译期常量表达式，比如 has_binding_v<t></t>。这个值必须由模板特化显式提供，不能靠运行时注册补救。
- 没写
template struct binding<ilogger> { using type = ConsoleLogger; };</ilogger>→resolve<ilogger>()</ilogger>编译失败，错误指向缺失特化 - 写了但
ConsoleLogger不满足ILogger的接口契约（比如虚函数签名不一致）→ 编译失败在构造对象时，而非 resolve 调用点 - 特化了两次同个类型（如两个
binding<ilogger></ilogger>）→ 链接错误或 ODR 违反，取决于实现方式
binding<t></t> 特化必须定义在头文件里
模板特化不是普通函数，它参与编译单元的实例化。如果把 binding<databaseinterface></databaseinterface> 写在 database.cpp 里，其他包含该头的源文件根本看不到这个特化，resolve<databaseinterface>()</databaseinterface> 就会退回到默认（通常是空实现或 static_assert(false)）。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 所有
binding必须声明 + 定义在头文件中（通常随接口头一起发布） - 避免在多个 TU 中重复定义同一特化；C++ 要求 ODR 合规，否则链接时报
duplicate symbol - 若需条件绑定（如
ENV == prod），改用#ifdef或constexpr if分支，而不是靠不同 cpp 文件注册不同实现
构造函数参数无法自动推导，必须显式传入
编译期 DI 不支持“自动装配”：你不能只写 resolve<myservice>()</myservice> 就让框架去查 MyService 的构造函数、再递归 resolve 其参数类型。C++ 模板无法在不实例化的情况下反射构造签名。
- 要么手动构造：
MyService{resolve<ilogger>(), resolve<idatabase>()}</idatabase></ilogger> - 要么用辅助模板（如
make_from_bindings<myservice>()</myservice>），但它内部仍需硬编码参数顺序和类型 - 若
MyService构造函数带非依赖参数（如int timeout_ms），必须显式提供，无法靠容器注入
单例生命周期必须由调用方严格控制
编译期系统不管理对象生存期——它只负责“怎么造”，不负责“造几次”或“何时析构”。所谓 singleton，其实是靠静态局部变量或全局变量实现，而它们的析构顺序是未定义的。
- 别在
binding特化里直接返回static ConsoleLogger instance;—— 多线程首次调用可能竞态 - 更安全的做法是返回
std::unique_ptr<t></t>，由上层决定是否缓存（例如在 main 开头一次性 resolve 所有单例并 hold 住） - 跨 DLL/so 边界时，静态变量可能被多次初始化，此时必须用指针 + 构造标志位，或彻底放弃编译期 singleton，改用运行时容器托管
最易被忽略的是：编译期 DI 看似“零成本”，但一旦开始用模板递归展开依赖链（比如 make_from_bindings 嵌套 resolve），编译时间会指数增长，且错误信息极难定位。与其强行覆盖所有场景，不如把核心服务用编译期绑定，外围策略类用 std::function 或模板参数传入——边界清晰，编译快，调试也直白。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
