C++装饰器模式是手动实现的设计模式，通过组合+虚接口动态叠加行为，核心是定义含虚析构函数的抽象组件接口，装饰器持智能指针包装并转发调用。
装饰器模式在C++里没有语言原生支持
C++不提供像Python @decorator那样的语法糖，所谓“C++装饰器模式”是纯手动实现的设计模式，本质是通过组合+虚接口来动态叠加行为。别被名字带偏——它和Python装饰器完全不是一回事，也没有运行时注入函数的能力。
核心思路：定义抽象组件接口，让原始类和所有装饰器都继承它；装饰器内部持有一个指向该接口的指针（或引用），在转发调用前后插入逻辑。
必须先定义统一的抽象接口Component
没有这个基类，就无法用多态统一处理原始对象和任意层数的装饰器。漏掉virtual析构函数会导致内存泄漏，这是高频翻车点。
-
Component必须有虚析构函数（哪怕空实现） - 所有要被增强的方法必须声明为
virtual，否则装饰器无法重写 - 避免返回具体类型，优先用
Component&或std::unique_ptr保持接口一致性
示例：
struct Component {
virtual ~Component() = default;
virtual void operation() = 0;
};
装饰器类必须持有Component*并转发调用
装饰器不是继承原始类，而是“包装”它。常见错误是直接继承被装饰类（如class LoggingDecorator : public ConcreteComponent），这会破坏模式的可组合性，导致无法嵌套（比如日志+缓存+权限三层叠加）。
- 构造函数必须接收
std::unique_ptr或Component*，推荐智能指针管理所有权 - 每个装饰器只负责自己那层逻辑：前置/后置/条件拦截/异常处理等
- 调用
component_->operation()前或后加自己的代码，不能漏掉转发
典型结构：
class LoggingDecorator : public Component {
std::unique_ptr<component> component_;
public:
explicit LoggingDecorator(std::unique_ptr<component> c) : component_(std::move(c)) {}
void operation() override {
std::cout operation(); // 必须转发！
std::cout <h3>堆上构造+智能指针链式组装是唯一安全方式</h3>
<p>栈对象组合会引发切片或悬挂指针。例如<code>LoggingDecorator{CacheDecorator{ConcreteComponent{}}}</code>看似简洁，但中间临时对象一销毁，外层装饰器持有的指针就野了。</p>
<ul>
<li>必须用<code>std::make_unique</code>逐层构建，确保生命周期由最外层智能指针控制</li>
<li>不要裸指针传递，避免所有权模糊（谁delete？）</li>
<li>如果原始类不可修改，需用适配器包装成<code>Component</code>子类</li>
</ul>
<p>正确组装：</p>
<pre class="brush:php;toolbar:false;">auto base = std::make_unique<concretecomponent>();
auto cached = std::make_unique<cachedecorator>(std::move(base));
auto logged = std::make_unique<loggingdecorator>(std::move(cached));
logged->operation(); // 安全调用</loggingdecorator></cachedecorator></concretecomponent>
复杂点在于每层装饰器都要自己管理状态（如缓存map、日志级别），且无法像Python那样对已有函数零侵入增强——C++的装饰器模式注定是编译期契约、运行期组合，灵活性和成本永远是一体两面。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
