大多数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 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));
</ilogger></ilogger></consolelogger>
什么时候该用std::shared_ptr而不是std::unique_ptr
当多个对象需要共享同一依赖实例（比如全局配置、连接池、日志器），且生命周期不确定时，std::shared_ptr更合适。但要注意循环引用风险。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 共享依赖必须是线程安全的，否则需额外加锁
-
std::weak_ptr用于打破循环引用，尤其在回调或观察者模式中 - 不要为“看起来统一”而全用
shared_ptr——独占语义更清晰、性能略好
错误示范：shared_ptr被无意识拷贝导致意外延长生命周期：
// ❌ 隐式拷贝，可能让对象活太久
void process(std::shared_ptr<dbconnection> conn) {
auto cached = conn; // 新引用计数+1，conn析构不等于资源释放
}
</dbconnection>
避免用模板参数硬编码依赖类型
像template<typename loggerimpl> class Service</typename>这种写法看似灵活，实则破坏了运行时替换能力，也增加编译膨胀和测试难度。
- 模板注入适合零成本抽象场景（如数学库），不适合业务逻辑层
- 若真要泛型构造，优先用类型擦除（如
std::function<:unique_ptr>()></:unique_ptr>）而非模板参数 - 测试时无法轻松注入mock——你得为每个mock类型特化整个类
真正简洁的做法：依赖抽象接口 + 构造函数参数 + 工厂函数组合。复杂度可控，调试路径清晰，改起来不牵一发而动全身。
真正麻烦的从来不是怎么写注入，而是决定哪些依赖该被注入、哪些该内联、哪些该用单例——边界划错，再漂亮的DI也是负担。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
