大多数C++项目无需手写完整DI容器，应优先采用工厂函数+std::unique_ptr实现轻量解耦：抽离构造逻辑、明确所有权、支持mock测试、编译调试高效。
依赖注入在C++里到底要不要手写容器
大多数C++项目不需要完整DI容器——它不是Java或C#，没有运行时反射，硬搞IoC容器容易过度设计。真正需要的，往往是解耦构造逻辑、控制依赖生命周期、方便单元测试。直接用工厂函数 + 智能指针组合，比引入第三方库更轻量、更可控。
用std::unique_ptr和工厂函数做构造解耦
这是最常用也最安全的方式：把对象创建逻辑抽离成独立函数，返回std::unique_ptr，调用方只依赖接口指针，不关心具体类型。
- 避免裸指针和内存泄漏：强制所有权语义，析构自动释放
- 工厂函数可按需注入不同实现（比如测试时返回mock）
- 不依赖宏或模板元编程，编译快、调试直观
示例：
class ILogger {
public:
virtual void log(const std::string& msg) = 0;
virtual ~ILogger() = default;
};
class ConsoleLogger : public ILogger {
public:
void log(const std::string& msg) override { std::cout << "[LOG] " << msg << "\n"; }
};
// 工厂函数 —— 这就是注入点
std::unique_ptr<ILogger> createLogger() {
return std::make_unique<ConsoleLogger>();
}
class Service {
std::unique_ptr<ILogger> logger_;
public:
explicit Service(std::unique_ptr<ILogger> logger) : logger_(std::move(logger)) {}
void doWork() { logger_->log("doing work"); }
};
// 使用时注入
auto logger = createLogger();
Service svc(std::move(logger));
什么时候该用std::shared_ptr而不是std::unique_ptr
当多个对象需要共享同一依赖实例（比如全局配置、连接池、日志器），且生命周期不确定时，std::shared_ptr更合适。但要注意循环引用风险。
立即学习“C++免费学习笔记（深入）”；
- 共享依赖必须是线程安全的，否则需额外加锁
-
std::weak_ptr用于打破循环引用，尤其在回调或观察者模式中 - 不要为“看起来统一”而全用
shared_ptr——独占语义更清晰、性能略好
错误示范：shared_ptr被无意识拷贝导致意外延长生命周期：
// ❌ 隐式拷贝，可能让对象活太久
void process(std::shared_ptr<DBConnection> conn) {
auto cached = conn; // 新引用计数+1，conn析构不等于资源释放
}
避免用模板参数硬编码依赖类型
像template<typename LoggerImpl> class Service这种写法看似灵活，实则破坏了运行时替换能力，也增加编译膨胀和测试难度。
- 模板注入适合零成本抽象场景（如数学库），不适合业务逻辑层
- 若真要泛型构造，优先用类型擦除（如
std::function<std::unique_ptr<T>()>）而非模板参数 - 测试时无法轻松注入mock——你得为每个mock类型特化整个类
真正简洁的做法：依赖抽象接口 + 构造函数参数 + 工厂函数组合。复杂度可控，调试路径清晰，改起来不牵一发而动全身。
真正麻烦的从来不是怎么写注入，而是决定哪些依赖该被注入、哪些该内联、哪些该用单例——边界划错，再漂亮的DI也是负担。
