C++ 装饰器模式需手动实现，通过继承统一抽象基类、使用 shared_ptr 组合对象链，避免循环引用与析构错误；适合正交功能扩展，但链过深影响性能，动态需求必须用虚函数版而非模板。
装饰器模式在 C ++ 里没有语法糖，得靠组合和虚函数手动搭
Python 的 @decorator 是语言层支持，C++ 没有。想实现类似“运行时动态加日志、校验、缓存”，必须自己建接口基类，用指针或智能指针链式持有被装饰对象——本质是对象组合，不是语法修饰。
常见错误现象：std::shared_ptr<base> ptr = std::make_shared<decoratora>(std::make_shared<concrete>());</concrete></decoratora>写成栈对象嵌套（如 DecoratorA{Concrete{}}），导致析构顺序错乱或悬垂引用；或者忘了让Decorator 继承同一抽象基类，导致无法继续套娃。
- 所有装饰器和被装饰对象必须共用一个纯虚接口（比如
virtual void execute() = 0;） - 装饰器构造函数必须接收
std::shared_ptr<Base>（不能是裸指针，避免所有权模糊） - 每个装饰器只负责自己那层逻辑，调用
m_component->execute()把控制权往下传
如何避免装饰器链过深导致的性能与调试问题
每层装饰器都是一次虚函数调用 + 一次堆内存访问，10 层链就可能比直接调用慢 2–3 倍，而且 gdb 里单步会跳来跳去，很难定位到底哪一层改了输入输出。
使用场景：适合功能正交、开关粒度较粗的扩展（比如统一加权限检查、统一打耗时日志），不适合高频小操作（如给每个 get_value() 加原子计数）。
立即学习“C++ 免费学习笔记（深入）”；
- 用
std::optional<std::chrono::steady_clock::time_point>在基类里埋计时钩子，而非每层都写auto start = …… - 调试时临时加
if (m_debug_tag) std::cout << "[Log] " << typeid(*this).name() << "n";，别依赖 IDE 断点连跳 - 超过 4 层建议重构：把几个固定组合抽成新具体类（如
AuthCachedLoggerService），而不是硬堆AuthDecorator→CacheDecorator→LogDecorator→RetryDecorator
std::shared_ptr 循环引用？别让装饰器同时持有组件又暴露自身为组件
典型错误：装饰器内部存std::shared_ptr<Base> m_component;，又在某个接口里返回this（或shared_from_this()）给外部再包装——立刻触发循环引用，对象永不析构。
参数差异：std::weak_ptr<Base>不能用于构造新装饰器（因为可能已释放），但可安全用于回调或延迟访问；而 std::shared_ptr 必须确保生命周期由最外层持有者完全掌控。
- 装饰器类 ** 不要 ** 继承
std::enable_shared_from_this，除非你明确需要对外暴露shared_from_this() - 如果必须传递自身，用
std::shared_ptr<const Base>返回只读视图，切断修改路径 - 单元测试里用
std::weak_ptr观察生命周期：auto w = ptr; ptr.reset(); assert(w.expired());
为什么不用模板实现静态装饰器？它和运行时装饰器根本不是一回事
有人用 template<typename T> class Logged : public T 搞 CRTP，看起来更轻量，但它在编译期就决定了装饰顺序，没法根据配置文件或用户权限动态启用 / 禁用某一层。
性能影响：模板版本零开销，但失去灵活性；虚函数版本有间接成本，换来的是运行时策略切换能力——选哪个，取决于你的“动态”到底动在哪。
- 配置驱动的系统（如微服务中间件）必须用虚函数版，否则每次改日志开关都要重编译
- 嵌入式资源受限场景，若装饰逻辑固定，可用模板 +
if constexpr裁剪，但注意sizeof(Logged<TcpClient>)可能比原类型大很多 - 混合方案可行：外层用虚函数做主干（
ServiceInterface），内层用模板优化热点路径（如BufferedWriter<TcpStream>）
真正难的不是写对虚函数调用链，而是划清“哪些该动态决定、哪些该编译期固化”。一旦需求里出现“运营后台可实时开关缓存”，就只能老老实实走指针链。
