C++依赖注入需手动实现，核心是接口抽象+构造函数注入+智能指针管理；避免内部new和全局单例，优先用std::shared_ptr共享依赖，慎用第三方DI容器。
在 C++ 中无法像 Java 或 C# 那样靠语言级注解或运行时反射自动完成依赖注入，必须手动管理对象生命周期和依赖关系。核心思路是：用抽象（接口）隔离实现，用构造函数或 setter 显式传入依赖，再配合工厂、智能指针或轻量级容器控制创建时机。
用纯虚类定义接口 + 构造函数注入
这是最直接、无第三方库的方式，适合中等规模项目。关键不是“注入”本身，而是避免 new 硬编码和全局单例。
常见错误现象：类内部直接 new ConcreteService()，导致无法替换实现、难以单元测试。
- 定义纯虚接口（如
ILogger），所有实现类继承它 - 依赖方（如
Processor）只持有std::unique_ptr或引用，通过构造函数接收 - 创建时由上层决定传哪个实现：
Processor p{std::make_unique()} - 不要在构造函数里做耗时操作或抛异常——这会让注入点变得脆弱
用 std::shared_ptr + 工厂函数解耦生命周期
当多个组件共享同一依赖实例（如配置管理器、数据库连接池），且生命周期需统一管理时，std::shared_ptr 比裸指针或 unique_ptr 更合适。
立即学习“C++免费学习笔记（深入）”；
使用场景：日志器、配置服务、HTTP 客户端等跨模块共享对象。
- 工厂函数返回
std::shared_ptr，而非具体类型 - 所有使用者拿到的是同一份引用计数的实例，无需关心谁释放
- 注意循环引用：若 A 持有
shared_ptr且 B 持有shared_ptr，需对其中一方改用weak_ptr - 工厂内可读配置、选实现（如根据
ENV=prod返回ProdDatabase）
避免过度设计：什么时候不该用 DI 容器？
C++ 项目引入 boost.di 或 GracefulDI 等第三方 DI 库前，先确认是否真需要——它们会增加编译时间、模板膨胀和调试难度。
容易踩的坑：
- 把简单工具类（如
StringUtils、JsonParser）也塞进容器，反而让调用路径不透明 - 容器注册逻辑分散在多个 cpp 文件，启动时才发现依赖缺失或类型不匹配（C++ 编译期不报错，链接期才失败）
- 误以为“自动注入”能替代清晰的职责划分——如果一个类需要 7 个依赖，大概率它违反了单一职责原则
- 在嵌入式或实时系统中滥用动态内存分配（DI 容器内部常隐式 new 对象）
最小可行示例：构造函数注入 + shared_ptr 管理
以下代码展示如何不用任何第三方库，实现可测试、可替换的日志依赖：
#include#include #include struct ILogger { virtual ~ILogger() = default; virtual void log(const std::string& msg) = 0; };
struct ConsoleLogger : public ILogger { void log(const std::string& msg) override { std::cout << "[CONSOLE] " << msg << "\n"; } };
struct FileLogger : public ILogger { explicit FileLogger(const std::string& path) : m_path(path) {} void log(const std::string& msg) override { std::cout << "[FILE:" << m_path << "] " << msg << "\n"; } private: std::string m_path; };
struct Service { explicit Service(std::shared_ptr
logger) : m_logger(std::move(logger)) {} void doWork() { m_logger->log("processing..."); } private: std::shared_ptr m_logger; }; // 使用方式 int main() { auto logger = std::make_shared
(); Service svc(logger); svc.doWork(); // 输出 [CONSOLE] processing... }
真正难的不是写这几行代码，而是坚持在每个新类里问一句：“这个 new 能不能挪到外面？这个头文件依赖能不能换成前向声明+指针？”
