核心是用std::unordered_map以std::type_index为键、std::function为值实现类型安全的运行时依赖注入，注册时封装构造逻辑，resolve时static_pointer_cast转换，避免RTTI与裸指针。
如何用 std::unordered_map 实现接口到实现类的运行时映射
依赖注入的核心是解耦接口与具体实现，C++ 没有原生反射，所以得靠手动注册 + 类型擦除。最轻量的方式是用 std::unordered_map 存接口类型 ID（如 std::type_index）到工厂函数指针的映射。
别直接存裸指针或 new 出来的对象——生命周期难控。应该存 std::function<:shared_ptr>()></:shared_ptr>，把构造逻辑封装进去，由容器统一管理对象生命周期。
-
std::type_index(typeid(Interface))是安全的类型键，比字符串快且无拼写风险 - 工厂函数必须返回
std::shared_ptr<void></void>，后续靠std::static_pointer_cast安全转回目标类型 - 注册时若重复覆盖，需明确日志提示，否则后期替换失败却无报错
为什么 register_instance 要区分单例 vs 每次新建
注册一个已构造好的对象（register_instance）和注册一个构造器（register_type）行为完全不同：前者绑定的是固定实例，后者每次 resolve 都调用一次工厂函数。
常见错误是把临时对象传给 register_instance，比如 container.register_instance<logger>(Logger())</logger> —— 这会导致绑定一个栈上对象，后续访问即未定义行为。
立即学习“C++免费学习笔记（深入）”；
- 必须用
std::make_shared构造后传入，例如container.register_instance<logger>(std::make_shared<filelogger>())</filelogger></logger> - 单例模式下，
register_instance和register_type的语义差异直接影响线程安全：前者天然线程安全（只注册一次），后者若没加锁，多线程首次 resolve 可能触发多次构造 - 如果注册的是带参数的构造器，建议用 lambda 捕获依赖项，但注意捕获方式：值捕获易导致悬挂引用，推荐用
std::shared_ptr传参
resolve() 如何避免 dynamic_cast 和 RTTI 开销
直接用 dynamic_cast 做类型转换不仅慢，还要求基类有虚函数（开启 RTTI）。更优解是注册时就用模板推导出目标类型，在 map 中存 std::shared_ptr<t></t> 的包装器，resolve 时直接 static_pointer_cast。
关键点在于：map 的 value 类型不能是裸 void*，而应是类型擦除后的可调用对象，其内部已知目标 T。
- 实际存储结构建议为
std::unordered_map<:type_index std::function>()>></:type_index>，resolve 时调用工厂，再用std::static_pointer_cast<t></t>转换 - 不要在 resolve 里做
if (type == typeid(A)) return cast<a>(); else if (type == typeid(B))...</a>—— 编译期无法优化，且新增类型就得改代码 - 如果项目禁用 RTTI，
std::type_index仍可用（它不依赖 RTTI），但需确认编译器支持（GCC/Clang/MSVC 均支持）
容器线程安全边界在哪
绝大多数轻量 DI 容器默认不保证线程安全，注册（register_*）通常只在启动阶段调用，但 resolve 可能在任意线程高频调用。因此，读多写少场景下，只需对注册路径加锁，resolve 路径保持无锁。
容易被忽略的是：即使 resolve 不修改容器，如果工厂函数内部创建对象时用了静态局部变量（如单例初始化），仍可能引发 data race。
- 注册操作（
register_instance/register_type）必须加互斥锁，建议用std::mutex或std::shared_mutex（C++17） - resolve 操作本身可无锁，但要确保工厂函数是纯函数或自身线程安全
- 避免在工厂 lambda 中捕获非线程安全对象（如全局
std::ofstream），这类状态应封装进被构造对象内部
真正难的不是注册和解析逻辑，而是让所有工厂函数的生命周期、捕获变量、异常处理都收敛到同一套规则里。一旦某处用 new 替代 make_shared，或忘了在 lambda 里加 mutable 却修改了捕获值，整个容器的内存模型就不可靠了。
