纯模板编译期依赖注入需显式声明依赖并特化service_impl，std::is_constructible_v仅校验构造语法可行性，inject()须递归解析参数，循环依赖须运行时检测，所有注册点必须inline constexpr。
纯模板的编译期依赖注入在 C++ 里能跑通，但不等于“写完就能用”——它必须显式声明所有依赖关系，且任何一处类型未完整定义、特化遗漏或构造参数不匹配，都会导致晦涩的模板错误，而不是清晰的“找不到服务”提示。
std::is_constructible_v 是检查注入可行性的正确工具，不是自动注册开关
很多人误以为只要 std::is_constructible_v<service args...></service> 返回 true，系统就能自动把 Service 注入进去。其实它只回答“语法上能否构造”，完全不管“依赖是否已注册”“参数从哪来”“生命周期怎么管”。比如 DatabaseService 需要 ConnectionPool&，它不可默认构造，但 std::is_constructible_v<databaseservice connectionpool></databaseservice> 可能为 true —— 这只是注入的前提，不是充分条件。
实操建议：
- 仅用
std::is_constructible_v做注入前校验，别用它触发注册逻辑 - 真正注册靠显式特化，例如
template struct service_impl<ilogger> { using type = ConsoleLogger; };</ilogger> - 未特化的接口类型在调用
inject<ilogger>()</ilogger>时会报 “no member named ‘type’”，错误位置直指调用点，比链接错误好定位得多 - 避免用
std::is_default_constructible_v判断可注入性，它会把带参构造的服务直接判为“不可注入”
inject() 必须递归解析构造参数，不能靠一次 decltype 推导
inject<t>()</t> 看似是个函数，实则是编译期元函数：它得展开 T 的构造函数签名，对每个参数类型再次调用 inject<arg>()</arg>，最后拼出完整构造表达式，如 T{inject<depa>(), inject<depb>()}</depb></depa>。如果只做一层 decltype(T{})，就卡死在无参构造上，根本走不通真实服务链。
立即学习“C++免费学习笔记（深入）”；
常见错误现象：定义了 ServiceA 依赖 ServiceB，但 inject<servicea>()</servicea> 编译失败，错误堆栈里全是 std::declval 和 std::is_constructible 展开失败，找不到具体哪一环断了。
实操建议：
- 用
requires约束替代裸static_assert，让不满足条件的重载直接被 SFINAE 踢出候选集，错误信息更短、更准 - 每个
inject<arg>()</arg>调用都应附带static_assert(dependency_registered_v<arg>, "...")</arg>，确保问题暴露在参数层，而非最终构造层 - 若某依赖需运行时参数（如端口号），不能塞进纯编译期路径；必须拆出
register_factory<t>(std::function<:unique_ptr>(int port)>)</:unique_ptr></t>分层处理
循环依赖只能靠运行时标记检测，编译期 static_assert 会静默失效
模板递归展开遇到循环依赖（A → B → A）时，编译器通常不会报“循环依赖”，而是爆栈、内存耗尽或给出超长未实例化模板列表。你写的 static_assert(!is_in_path_v<a path>)</a> 在编译期无法真正“跟踪路径”，因为 path 是类型列表，不是可变状态。
性能与兼容性影响明显：纯编译期环检测只适用于极小规模 DAG；真实项目中必须引入运行时 in_resolving_ 标记位，配合线程局部存储或原子 flag，在首次 resolve() 时拦截重复进入。
实操建议：
- 编译期只做轻量级拓扑可满足性检查（如
dependencies_of<t></t>是否为空或仅含已知类型），不模拟 DFS 路径 - 运行时 resolve 阶段加
thread_local std::unordered_set<:type_info const> in_resolving_</:type_info>，并在析构时自动清理 - 不要试图用
constexpr std::vector或std::array存路径 —— C++20 不支持 constexpr 容器修改，会直接编译失败
最易被忽略的一点：所有注册点（service_impl 特化、is_registered 变量、inject_context 实例）必须声明为 inline constexpr，否则多翻译单元下 ODR 违规，GCC/Clang 可能静默接受，MSVC 直接链接失败。这不是风格问题，是 ABI 层面的硬约束。
