C++无原生装饰器语法，需用继承+组合+虚函数模拟装饰器模式；核心是抽象基类、virtual接口、shared_ptr管理生命周期，避免裸指针和析构顺序错误。
为什么 C++ 没有原生装饰器语法，但你仍要手写 Decorator 类
C++ 不像 Python 那样支持 @decorator 语法糖，所谓“装饰器模式”在 C++ 里本质是靠继承 + 组合 + 接口抽象来模拟的。它不是为了炫技，而是当你需要在运行时动态叠加行为（比如日志、缓存、权限校验），又不想修改原始类或产生大量子类时的务实选择。
常见错误现象：std::shared_ptr<Base> 被传入后，装饰器调用虚函数却没走重写逻辑——多半是基类函数没声明为 virtual，或者派生类没用 override 显式标注。
- 必须确保被装饰的接口是抽象基类，核心方法声明为
virtual（纯虚更安全） - 装饰器类本身也得继承该基类，并在构造函数中接收一个
std::shared_ptr<Base>或Base&（后者需注意生命周期） - 避免裸指针传递：用
std::shared_ptr管理所有权，否则装饰链断裂或提前析构会导致未定义行为
如何写一个可链式叠加的 LoggingDecorator
典型使用场景：给已有 NetworkService 加日志，再加重试，再加超时——每层只关心自己那部分逻辑，不侵入下层实现。
参数差异关键点：装饰器构造函数接受的是被装饰对象，不是类型名；返回新对象时用 std::make_shared 包装，别直接 new。
立即学习“C++免费学习笔记（深入）”；
class Service {
public:
virtual ~Service() = default;
virtual std::string call() = 0;
};
class NetworkService : public Service {
public:
std::string call() override { return "data"; }
};
class LoggingDecorator : public Service {
std::shared_ptr<Service> inner_;
public:
explicit LoggingDecorator(std::shared_ptr<Service> inner) : inner_(std::move(inner)) {}
std::string call() override {
std::cout << "[LOG] before\n";
auto result = inner_->call();
std::cout << "[LOG] after\n";
return result;
}
};
- 不要在
LoggingDecorator::call()里直接 newNetworkService——这会破坏依赖注入原则，也难测试 - 如果装饰器需要持有状态（如重试次数），用成员变量 + 构造参数传入，别依赖全局或静态变量
- 性能影响：每次调用多一层虚函数分发，现代编译器对短虚函数可能内联，但链过长（>5 层）仍建议压测
用 std::unique_ptr 还是 std::shared_ptr？看所有权是否共享
错误现象：多个装饰器指向同一个 NetworkService 实例，其中一个析构后，其余调用崩溃——这是裸指针或 std::unique_ptr 被重复 move 的典型表现。
兼容性影响：C++11 起 std::shared_ptr 是安全底线；若项目禁用 RTTI，虚函数调用仍工作，但 dynamic_cast 失效，所以别在装饰器里做类型判断。
- 单条装饰链、明确生命周期（如局部作用域内组装）→ 用
std::unique_ptr<Service>更轻量 - 多个组件需共享同一被装饰对象（如日志和监控都包装同一个 service）→ 必须用
std::shared_ptr<Service> - 别混用：
std::shared_ptr构造的装饰器，不能再用std::unique_ptr接收其返回值
容易被忽略的析构顺序和资源泄漏点
装饰器链越长，析构顺序越关键。C++ 按构造逆序析构，但如果你在 Decorator 析构函数里调用了被装饰对象的方法（比如 flush 日志），而此时 inner 已经被销毁，就会 crash。
真实踩坑案例：TimeoutDecorator 在析构时试图 cancel 一个已 detach 的 std::thread，结果触发 std::terminate。
- 所有装饰器的析构函数必须是
noexcept，否则异常传播会终止程序 - 避免在析构中调用被装饰对象的任何非常量成员函数
- 若装饰器启动了线程或打开了文件，确保在析构前显式 stop/close，而不是依赖 RAII 自动清理（因为 inner 可能先于 decorator 析构）
最麻烦的其实是调试：虚函数调用栈看起来都是 Decorator::call → inner_->call()，实际断点得打在具体实现类里。别指望 IDE 自动跳转到最终目标函数。
