手写轻量ioc容器只为解决类型注册与实例获取，避免模板膨胀和rtti开销；用std::type_index+std::function实现类型映射，不支持循环依赖、自动生命周期管理及多线程注册。
为什么不用现成框架而要手写IoC容器
因为多数C++项目不需要Spring级别的功能，反而被模板膨胀、RTTI依赖和生命周期管理拖慢编译与运行。手写轻量级容器只解决两个事：register 类型绑定和 resolve 实例获取，其余都是干扰。
常见错误现象：用 std::any 或 void* 存储工厂函数，结果类型擦除后无法安全调用构造逻辑；或过度依赖宏做反射，导致调试困难、IDE跳转失效。
关键取舍点：
- 不支持循环依赖检测（手动保证注册顺序）
- 不自动管理对象生命周期（默认返回值语义，由使用者决定
std::shared_ptr还是栈对象） - 不处理多线程注册（初始化阶段单线程完成即可）
如何用 std::function + std::type_index 实现类型映射
核心是把“类型 → 构造逻辑”存进一个 std::unordered_map，键用 std::type_index{typeid(T)}，避免 typeid 比较开销；值用 std::function<:unique_ptr>()></:unique_ptr> 统一接口，内部强制转型。
立即学习“C++免费学习笔记（深入）”；
示例注册方式：
container.register_type<Database>([]() {
return std::make_unique<PostgresDB>("localhost:5432");
});
注意点：
- 必须用
std::unique_ptr<void></void>而非std::unique_ptr<t></t>，否则 map 值类型无法统一 -
resolve<t>()</t>内部需用static_cast<t>(ptr.get())</t>强转，不能用dynamic_cast（无虚函数则失败） - 若 T 无默认构造，工厂 lambda 必须显式传参，容器本身不提供参数注入能力
怎样避免 std::type_info::name() 在不同编译器下不可靠
std::type_index 是唯一可移植方案——它封装了 std::type_info，但重载了 operator== 和哈希，且标准保证同一类型的 std::type_index 比较恒等。别碰 std::type_info::name()，GCC/Clang/MSVC 输出格式完全不同，连空格都不一致。
典型翻车场景：
- 用
std::string(typeid(T).name())当 map key → 多平台构建失败 - 跨 shared library 边界传递
std::type_info*→ 比较永远为 false（即使类型相同） - 模板实例化在多个 TU 中发生 →
typeid可能生成不同实例（虽罕见，但std::type_index自动处理）
什么时候该放弃手写、直接用 std::optional<t></t> 或裸指针
如果项目里只有 3~5 个需要解耦的类，且生命周期完全由上层控制（比如游戏引擎的 InputSystem、AudioSystem 全局单例），那 std::optional<t></t> 初始化 + 引用传参比容器更轻、更易测试。
真实权衡点：
- 容器带来额外的虚函数表（如果用了基类抽象）、hash 计算、内存分配 —— 对嵌入式或热更新敏感场景是负担
- 若所有依赖都在 main() 开始前注册完毕，且无运行时替换需求，
static T instance{...}配合extern T& get_service()更快更透明 - 一旦需要 mock 单元测试、或模块热加载，才真正需要容器的动态绑定能力
最常被忽略的是：容器本身不该成为新依赖源。它的头文件必须不引入第三方、不含宏、不依赖 Boost 或 fmt，否则就违背“轻量”初衷。
