C++无@decorator语法，装饰器模式需用继承+组合模拟：定义抽象Component接口，Decorator持Component指针/智能指针并转发调用；须防内存泄漏、悬挂指针及虚函数开销。
装饰器模式在C++里为什么不能像Python那样写@decorator
C++没有运行时函数注解机制，@decorator这种语法根本不存在。所谓“C++实现装饰器模式”，本质是用类继承+组合模拟行为增强，核心是遵守“对扩展开放、对修改关闭”——新增功能不改原有类，而是包一层新类。
容易踩的坑是直接继承并重写所有方法，结果变成模板爆炸或虚函数开销失控；更常见的错误是忘了让装饰器持有被装饰对象的指针/引用，导致调用链断裂。
最简可行的Component + Decorator基类结构
必须定义抽象接口（Component），所有具体类和装饰器都实现它。装饰器自身也是Component，但内部持有一个Component*（或std::unique_ptr<component></component>）。
-
Component只声明纯虚函数，比如virtual void operation() = 0; -
Decorator继承Component，构造时接收Component*，保存为成员变量 - 每个具体装饰器（如
LoggingDecorator）重写operation()：先做自己的逻辑（如打印日志），再调用component_->operation()
示例关键片段：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
class Component {
public:
virtual void operation() = 0;
virtual ~Component() = default;
};
<p>class Decorator : public Component {
protected:
Component<em> component_;
public:
explicit Decorator(Component</em> c) : component_(c) {}
};</p><p>class LoggingDecorator : public Decorator {
public:
explicit LoggingDecorator(Component* c) : Decorator(c) {}
void operation() override {
std::cout << "[LOG] before\n";
component_->operation();
std::cout << "[LOG] after\n";
}
};如何避免内存泄漏和悬挂指针
装饰器生命周期必须长于被装饰对象，否则component_会成野指针。常见做法有三种：
- 用
std::unique_ptr<component></component>管理所有权（推荐）：装饰器负责释放被装饰对象，适合一次性包装链 - 用
std::shared_ptr<component></component>：多个装饰器共享同一底层对象，但要注意循环引用风险 - 传入裸指针 + 明确约定生命周期（如被装饰对象是栈变量且作用域更大）：轻量但危险，调试时崩溃难定位
若用unique_ptr，Decorator构造函数应改为explicit Decorator(std::unique_ptr<Component>&& c)，并在派生类中用std::move传递。
多层装饰时的性能与可读性陷阱
连续套用new TimingDecorator(new LoggingDecorator(new ConcreteComponent()))既难读又易错。建议封装工厂函数或使用RAII包装：
- 写个
make_decorated函数，接受可变参数包，按顺序组装（需C++17折叠表达式） - 避免在装饰器里做耗时操作（如磁盘I/O），否则叠加后延迟不可控
- 调试时注意虚函数调用栈：IDE可能只显示
LoggingDecorator::operation，实际执行流已跳转多次
装饰器链越长，虚函数间接调用越多，LTO编译可能优化掉部分开销，但别依赖它——关键路径上优先考虑策略模式或编译期模板装饰（如std::optional包装返回值）。
真正麻烦的是状态维护：比如一个RetryDecorator需要保存重试次数，但它不知道底层组件是否线程安全。这种耦合点，文档比代码更关键。
