纯模板实现的自动派发依赖注入在C++中不可行——它无法绕过运行时类型擦除与对象生命周期管理的核心矛盾。
纯模板实现的自动派发依赖注入在 C++ 中不可行——它无法绕过运行时类型擦除与对象生命周期管理的核心矛盾。
为什么 std::function 和 std::any 不可避免
模板在编译期展开，但依赖注入的本质是「运行时决定构建哪个实例」。比如配置文件指定加载 MySQLDatabase 还是 PostgreSQLDatabase，这两者无公共基类时，模板无法生成统一接口；即使有基类，工厂返回指针/引用也必须经由多态或类型擦除才能存入容器。
- 试图用
template<typename T> T resolve()强制用户写死类型，等于放弃「自动派发」——调用方得提前知道具体类型，和 new 一个对象没区别 -
std::variant<A, B, C>只能预设有限类型列表，无法支持插件式扩展（如第三方模块注册新服务） - 所有「纯模板 DI 容器」实际都悄悄用了
void*、std::any或虚函数，只是把类型擦除逻辑藏在了模板内部
resolve<T>() 调用背后的真实开销
看似零成本的模板函数，一旦涉及跨模块服务查找或线程安全初始化，就会暴露隐性成本：
- 首次
resolve<Logger>()可能触发单例构造 + 全局锁，不是编译期常量 - 若用
std::map<std::type_info*, std::shared_ptr<void>>存储实例，每次resolve都要查哈希表 +std::any_cast或dynamic_cast，比虚函数调用还重 - Clang/GCC 对跨编译单元的模板内联不保证，可能产生冗余符号或链接时重复实例化
工程中真正可用的轻量级方案
放弃「全自动」幻想，用最小运行时支撑最大灵活性：
立即学习“C++免费学习笔记（深入）”；
- 注册阶段显式声明类型：
container.register_type<Database>().as<IDatabase>().with_factory([]{ return std::make_unique<MySQLDatabase>(); }); - 解析时仍需类型标注，但允许 fallback：
auto db = container.resolve<IDatabase>().value_or(std::make_shared<MockDatabase>()); - 关键路径避免反射：用宏或 CMake 生成
type_id常量（如constexpr uint64_t type_hash = 0x8a3f2c1e4d5b6a7cULL;），替代typeid(T).hash_code()的 ABI 不稳定性 - 生命周期交给 RAII：注册时指定
.as_singleton()或.as_transient()，容器只管调用构造/析构，不碰new/delete
最易被忽略的是线程局部注册表与主容器的同步时机——若允许模块在 dlopen 后动态注册服务，就必须用原子标志+读写锁，而不仅是 thread_local static 缓存。这点在嵌入式或热更新场景下直接导致崩溃。
