std::any不能替代依赖注入容器，因其仅支持运行时单值存储与类型识别，缺乏构造参数传递、生命周期管理、多实例绑定、延迟初始化及作用域控制等核心能力；依赖注入需注册“如何构建”，而非“存什么”。
为什么 std::any 不能直接替代依赖注入容器中的类型擦除
因为 std::any 只提供运行时类型识别和单值存储，不支持构造参数传递、生命周期管理、多实例绑定（如同一接口多个实现）、延迟初始化或作用域控制。依赖注入系统需要在注册时决定「如何构建对象」，而不仅仅是「存什么」。
实操建议：
- 用
std::function<:shared_ptr>()></:shared_ptr>封装工厂逻辑，把构造行为和类型信息一起捕获 - 注册时显式指定模板参数，避免靠
std::any推导——它无法还原模板实例化路径 - 若强行用
std::any存工厂，需额外维护一张type_index → factory映射表，且无法做编译期类型检查
如何让 injector::resolve<t>()</t> 支持非默认构造的依赖
关键不是重载 resolve，而是注册时就允许传入可调用对象，并在解析时原样调用。模板参数 T 决定返回类型，但不参与工厂选择逻辑。
实操建议：
- 注册接口设计为
bind<t>().to<f>()</f></t>或bind<t>().to([]{ return std::make_shared<impl>(arg1, arg2); })</impl></t> - 内部用
std::unordered_map<:type_index std::function>()>></:type_index>存储工厂，resolve<t>()</t>查找typeid(T)对应的工厂并调用 - 注意：工厂返回
std::shared_ptr<void></void>后必须static_cast回std::shared_ptr<t></t>，否则用户拿到的是裸指针或类型错误
为什么不能用 auto 推导注入容器的注册表类型
推导结果会是具名模板实例（如 std::unordered_map<:type_index std::function>></:type_index>），但该类型含未命名 lambda 或局部类，导致 ODR 违规或链接失败；更严重的是，不同编译单元中相同 lambda 类型可能被视为不同类型。
实操建议：
- 显式定义注册表类型别名，例如
using factory_map_t = std::unordered_map<:type_index std::function>()>>;</:type_index> - 所有工厂函数统一用
std::function包装，禁用未命名闭包直接注册 - 若需绑定成员函数，用
std::bind(&Class::create, &instance)或捕获 this 智能指针，确保生命周期可控
injector 类模板参数为何要限制为可复制构造的类型
因为注入器本身常作为单例或全局对象跨作用域使用，若其模板参数含不可复制类型（如含 std::unique_ptr 成员的类），会导致拷贝构造被隐式调用失败，报错类似 use of deleted function ‘X::X(const X&)’。
实操建议：
- 注入器自身不应模板化——它应是非模板类，内部用类型擦除管理所有注册项
- 真正需要模板化的只有
bind和resolve的接口函数，而非整个容器类 - 若坚持模板化容器，必须加
static_assert(std::is_copy_constructible_v<t>)</t>并给出清晰错误提示，而不是等链接时报晦涩错误
shared_ptr 的 capture 方式就让对象提前析构。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
