C++中装饰器模式需通过抽象基类、组合与虚函数手动实现，核心是装饰器持有被装饰对象智能指针并委托调用；应避免继承被装饰类，推荐用std::shared_ptr支持多层安全叠加，慎用虚调用优化与lambda替代。
装饰器模式在C++里没有语言原生支持，得靠类组合和虚函数手动实现
Python的@decorator是语法糖，C++没有对应机制。想复现“动态附加职责”的效果，核心是用抽象基类定义接口，让装饰器类持有被装饰对象指针，并在转发调用前后插入逻辑——本质是组合优于继承的实践。
常见错误是直接继承被装饰类（比如让LoggingDecorator继承Component），这会导致静态绑定、无法叠加多层装饰，且破坏开闭原则。
正确做法：
- 定义纯虚接口
Component，所有具体组件和装饰器都实现它 - 装饰器基类
Decorator继承Component，并持有一个std::unique_ptr<component></component>成员 - 每个具体装饰器（如
TimingDecorator）只重写需要增强的方法，其余方法直接委托给内部m_component
如何安全地叠加多个装饰器（比如日志 + 缓存 + 限流）
叠加的关键是构造顺序和所有权管理。装饰器必须能接收任意Component子类（包括其他装饰器），所以构造函数参数类型必须是std::unique_ptr<component></component>或std::shared_ptr<component></component>。
立即学习“C++免费学习笔记（深入）”；
推荐用std::shared_ptr避免转移后访问空指针，尤其在多层嵌套+异步场景下：
auto base = std::make_shared<ConcreteComponent>(); auto logged = std::make_shared<LoggingDecorator>(base); auto cached = std::make_shared<CachingDecorator>(logged); auto limited = std::make_shared<RateLimitingDecorator>(cached); limited->operation(); // 调用链：限流 → 缓存 → 日志 → 实际操作
容易踩的坑：
- 用
std::unique_ptr时，一旦转移给上层装饰器，原始指针就失效，不能再单独使用 - 装饰器析构顺序是反向的（最外层先析构），若内部有资源依赖需显式控制生命周期
- 不要在装饰器里缓存
Component*裸指针——shared_ptr计数归零后会悬空
性能敏感场景下，装饰器带来的虚函数调用开销怎么缓解
每层装饰器都会引入一次虚函数表跳转，叠加3层就是3次间接跳转。对高频调用路径（如网络包处理循环），这可能成为瓶颈。
可选优化手段：
- 用模板实现编译期装饰（类似CRTP），把装饰逻辑内联，但会失去运行时动态组合能力
- 对固定组合场景，手写一个融合类（如
LoggingAndTimingComponent），避免虚调用，代价是丧失灵活性 - 确认是否真有性能问题：先用
perf或vtune定位热点，别过早优化。多数业务代码中，虚调用开销远小于I/O或锁竞争
注意：final关键字不能加在装饰器类上——否则无法被进一步装饰；但可以加在最底层的具体组件类上，帮助编译器优化其虚调用。
为什么不用std::function或lambda模拟装饰器
有人尝试用std::function<void> wrapper = [&]{ log(); comp->operation(); };</void>，这只能包装无参无返回值的简单调用，且无法透传参数、捕获异常、访问被装饰对象状态。
更严重的问题是类型擦除丢失了接口契约：你无法把std::function当作Component传给期望该接口的函数，也无法在运行时判断它是否支持某个扩展方法（比如retry()）。
所以，只要需要：
- 统一接口（多态调用）
- 运行时动态堆叠
- 各装饰器独立管理自身状态（如缓存map、计数器）
就必须走虚函数+组合的经典路径。lambda适合做一次性切面，不适合构建可复用、可组合的装饰器体系。
真正麻烦的不是写法，而是设计时想清楚哪些职责该拆成装饰器、哪些该放进核心组件——边界模糊会导致装饰器之间开始互相依赖，或者为了透传状态而暴露不该公开的接口。
