ioc是设计思路而非c++语言特性，通过构造函数注入、接口抽象和创建使用分离实现解耦，无需第三方库，兼容c++11+，性能影响可忽略。
IoC 不是 C++ 语言特性，而是设计思路
控制反转（IoC）在 C++ 里没有内置语法支持，它本质是把对象创建和依赖绑定的“控制权”从类内部移出去。你不会看到 class IoCContainer 这种标准库类型，也不会有 @[Inject] 注解——C++ 没这玩意儿。它靠的是构造函数参数、指针/引用传递、工厂函数或轻量级容器手动管理来落地。
常见错误现象：new 硬编码在业务类里、std::unique_ptr<database> db_ = std::make_unique<mysqldatabase>();</mysqldatabase></database> 写死在构造函数中、单元测试时无法替换依赖。
- 使用场景：需要解耦模块（比如 Service 层不感知具体 Logger 实现）、写可测代码、替换第三方 SDK（如从 SQLite 切到 PostgreSQL）
- 核心原则：依赖抽象（接口类），而非具体实现；创建和使用分离
- 性能影响几乎为零——只是多一层指针间接访问，编译器常能内联优化掉
用纯虚基类 + 构造函数注入是最稳的起点
这是最贴近“依赖注入”本意的做法，不依赖第三方库，兼容所有 C++11+ 编译器，且 IDE 跳转、调试都清晰。
示例：一个 UserService 依赖 Logger 接口：
立即学习“C++免费学习笔记（深入）”；
struct Logger {
virtual ~Logger() = default;
virtual void log(const std::string& msg) = 0;
};
struct ConsoleLogger : Logger {
void log(const std::string& msg) override { std::cout << "[LOG] " << msg << "\n"; }
};
class UserService {
std::unique_ptr<Logger> logger_;
public:
explicit UserService(std::unique_ptr<Logger> logger)
: logger_(std::move(logger)) {}
void doSomething() { logger_->log("user created"); }
};
常见错误现象：UserService 自己 new ConsoleLogger；传入裸指针但生命周期失控；忘记 virtual ~Logger() = default 导致析构不完整。
- 必须声明虚析构函数，否则
delete派生类对象会未定义行为 - 优先用
std::unique_ptr<logger></logger>而非Logger*，明确所有权 - 不要用
std::shared_ptr除非真需要共享所有权——它带原子计数开销，且容易隐藏循环引用
避免过早引入“IoC 容器”库
像 cpp-ioc、di.hpp 或手写的泛型容器，在小型项目或模块初期反而增加理解成本和编译依赖。
常见错误现象：为注入一个 ConfigReader 引入 200 行模板元编程代码；容器注册逻辑散落在 main() 多个地方；编译失败时错误信息全是模板展开嵌套，根本看不出哪行错了。
- 真正需要容器的信号：依赖图复杂（A→B→C→D）、配置驱动绑定（如 JSON 指定用哪个实现）、或团队约定统一管理点
- 如果只有一两个依赖，直接在
main()或启动函数里 new 出来再传进去，更直白可靠 - 所有容器都绕不开生命周期管理问题——C++ 没 GC，谁
delete？谁持有std::shared_ptr？这点比 Java/Spring 容易出错得多
std::function 和策略模式是轻量替代方案
当依赖只是行为（不是状态化对象），用 std::function 更简洁，也规避了虚函数调用和继承体系。
示例：替换日志行为，而不是整个 Logger 对象：
class UserService {
std::function<void(const std::string&)> log_;
public:
explicit UserService(std::function<void(const std::string&)> log)
: log_(std::move(log)) {}
void doSomething() { log_("user created"); }
};
// 使用
UserService svc([](const std::string& s) { std::cerr << "[ERR] " << s << "\n"; });
常见错误现象：捕获局部变量后函数对象逃逸（如 lambda 捕获栈变量并存入类成员）；std::function 构造开销被忽略（尤其频繁调用场景）。
- 适合无状态、纯函数式行为注入（日志、序列化、校验规则）
- 注意捕获方式：
[&]危险，[=]可能拷贝大对象，优先用[&var]明确捕获 - 若性能敏感，且行为固定，考虑模板参数替代
std::function（零成本抽象，但会增加实例数量）
最易被忽略的点：依赖的生命周期必须严格长于使用者。哪怕用了最“现代”的注入方式，只要 Logger 对象在 UserService 还活着时被销毁，程序就崩——C++ 不救你，也没人提醒你。
