std::is_constructible_v 更适合判断注入可行性，因为它能检查含参数的构造合法性（如t(args...)），而 std::is_default_constructible_v 仅检测默认构造函数，对依赖其他服务的类型易误判为不可注入。
为什么 std::is_constructible_v 比 std::is_default_constructible_v 更适合判断注入可行性
编译期依赖注入的核心是：在实例化容器或解析器时，确认某类型能否被构造（含参数），而非仅看它有没有默认构造函数。很多服务类依赖其他服务指针，T(Args...) 合法但 T() 不合法——此时用 std::is_default_constructible_v 会误判为不可注入。
实操建议：
- 用
std::is_constructible_v<t args...></t>配合std::declval推导依赖项类型，例如：std::is_constructible_v<servicea std::shared_ptr>, std::shared_ptr<servicec>></servicec></servicea> - 避免硬编码参数列表，改用模板参数包展开 + SFINAE 约束，比如在
register_type中加static_assert校验可构造性 - 注意引用折叠问题：若传入
const T&类型依赖，需用std::add_lvalue_reference_t包装std::declval结果，否则推导失败
如何让 injector 在编译期拒绝循环依赖
循环依赖无法在运行时检测（因为所有类型信息在编译期已固定），必须靠模板实例化路径的重复展开触发 SFINAE 或 static_assert。常见错误是只检查直接构造参数，忽略间接依赖链（如 A→B→C→A）。
实操建议：
- 为每个注册类型维护一个“依赖路径”模板参数包，例如
inject_path<a b c></a>；当尝试构造C且路径中已含C，立即static_assert(false, "circular dependency detected") - 路径记录不能用
std::tuple（无法做类型存在性检查），而应使用递归变参模板，配合std::disjunction_v<:is_same ts>...></:is_same>判断重复 - 注意编译器对模板深度限制（如 GCC 默认 900），循环检测层级建议控制在 10 层内，超限时用
#pragma GCC diagnostic ignored "-ftemplate-depth"不推荐，应提前截断并报错
get_instance<t>()</t> 怎么避免运行时单例锁开销又保证线程安全
纯 constexpr 注入不现实（涉及动态内存分配和共享指针管理），但可以将“首次构造”延迟到第一次调用，并用 std::atomic_flag 替代 mutex 实现无锁初始化。常见错误是直接用 static local variable —— 它虽线程安全，但初始化时机不可控，且无法参与依赖图拓扑排序。
实操建议：
- 每个
T对应一个static inline std::atomic_flag flag = ATOMIC_FLAG_INIT和static inline std::shared_ptr<t> instance</t> - 在
get_instance中用flag.test_and_set(std::memory_order_acquire)原子判断，未设置则执行构造+赋值，再用std::atomic_thread_fence(std::memory_order_release)确保写可见 - 构造过程仍需按依赖顺序串行（即先
get_instance<b>()</b>再get_instance<a>()</a>），所以 injector 初始化函数必须显式声明依赖拓扑，不能靠调用顺序隐式推导
为什么不用 std::any 或 std::type_info 做注册表
编译期注入系统必须剔除任何运行时类型擦除行为。std::any 的 type() 返回 std::type_info*，其地址在不同编译单元可能不等价，导致跨模块注册失败；std::type_info::hash_code() 又非标准保证唯一，无法用于编译期常量比较。
实操建议：
- 注册表必须基于模板特化，例如
template<typename t> struct service_registry;</typename>，每个T对应独立特化实例 - 避免把类型名转成字符串（如
__PRETTY_FUNCTION__），那会破坏 ODR 和模块化，且无法用于constexpr if - 若需支持插件式扩展（如 DLL 加载后注册新服务），该能力必须由运行时注入层单独实现，与编译期核心解耦——两者不应共用同一套注册接口
最易被忽略的是依赖生命周期管理：编译期能推导出谁依赖谁，但无法决定谁先析构。shared_ptr 的销毁顺序与构造顺序相反，而依赖图的逆拓扑序未必等于实际对象创建顺序。这里需要显式约定或额外标记（如 [[no_destroy]] 或自定义 deleter），否则静态析构期访问已被释放的依赖会导致未定义行为。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
