说起来有点不好意思，我第一次在C++项目里系统性地用装饰器模式，是在一个消息处理服务上踩了好几次坑之后才真正理解它。当时需求看着也不复杂：消息进来，要做协议校验、鉴权、限流、日志、缓存，最后才落到真正的业务处理器上。第一版为了快，直接把逻辑写在Handler里，结果每个Handler里都是重复的样板代码，加一个埋点要改十几个文件。后来参考经典设计模式，把横切关注点拆成装饰器，业务代码确实清爽了，但新的麻烦也跟着来了——对象生命周期谁来管？拷贝一个装饰器会不会影响整条链？多线程并发访问缓存装饰器怎么保证安全？这些在GoF那本书里都没有现成答案，只能自己一遍遍在代码里试错。
这篇文章把这些实践整理出来。C++里装饰器模式分为三条路：继承式、函数式包装、模板组合，它们各自解决什么问题、有什么代价，以及缓存、重试、事务边界这三个生产场景中我实际踩过的坑。如果你正想把业务代码里的重复逻辑抽出来，或者在准备C++面试时被问到设计模式，这篇文章应该能给你一些可以落地的参考。
1. 为什么C++里的装饰器模式值得单独拎出来讲
1.1 教科书版本与C++语言特性的落差
教科书上装饰器模式的经典结构是这样：一个Component接口，一个ConcreteComponent实现，再加一个抽象Decorator持有一个Component引用，具体装饰器在调用前后附加逻辑。这个模型在Java、C#之类带GC的语言里跑得很顺，因为对象天然是引用语义，父类指针被子类覆盖后，程序员不用操心谁销毁谁，垃圾回收器兜底。
但C++没有这个待遇。类默认是值语义，拷贝一个对象可能把整条装饰链复制一遍；需要在堆上手动管理对象生命周期；多继承是合法的，但用不好就会出现菱形继承的幺蛾子。所以C++里的装饰器模式，核心难点从来不是“如何包装一个接口”，而是“如何管理包装链中对象的所有权、拷贝控制和异常安全”。
我在项目里见过一种很常见的崩法：装饰器内部用裸指针持有下一层对象，析构函数里不敢delete，怕外层把同一指针再释放一遍。二层装饰还好，三层以上基本没法控制。后来统一改成unique_ptr持有下一层，析构链自动释放，这个问题才彻底消失。
1.2 三条实现路线的选型标准
我按实现方式把C++的装饰器拆成三类：
第一类是继承式。装饰器类继承同一个接口，同时持有一个该接口的引用或智能指针。最接近GoF原意，适合接口稳定、装饰层数量不多、运行期需要动态组合的场景。
第二类是函数式。用std::function加lambda，装饰器本身是“接收一个回调，返回一个新回调”的高阶函数。适合只需要装饰“某个关键动作”而不是装饰“整个对象”的场景，业务代码改动最小。
第三类是模板式。用CRTP、模板叠加或template<template<typename> class... Decorators>把装饰层在编译期拼装好。没有虚函数开销，适合热路径、装饰结构静态已知、不需要运行期改变的场景。
选型的核心就一句话：装饰层的组合是编译期确定的，还是运行期可配置的？如果是运行期从配置文件或UI开关里决定用不用某几层，模板方案直接出局；如果是在每秒几百万次的循环里做装饰，std::function和虚函数带来的动态分发开销也要掂量一下。
2. 继承式装饰器：能跑通，但地雷比想象的多
2.1 一个经典的流处理示例
先看一个继承式装饰器的经典例子——数据流处理。定义一个Stream接口，然后实现FileStream，再用BufferedStream、EncryptedStream、CompressedStream逐层包装。
class Stream { public: virtual ~Stream() = default; virtual size_t read(char* buffer, size_t size) = 0; virtual size_t write(const char* buffer, size_t size) = 0; }; class FileStream final : public Stream { FILE* fp_ = nullptr; public: explicit FileStream(const char* path) { fp_ = fopen(path, "w+b"); } ~FileStream() override { if (fp_) fclose(fp_); } size_t read(char* buffer, size_t size) override { return fread(buffer, 1, size, fp_); } size_t write(const char* buffer, size_t size) override { return fwrite(buffer, 1, size, fp_); } }; class BufferedStream final : public Stream { std::unique_ptr<Stream> inner_; std::array<char, 4096> cache_{}; size_t cache_pos_ = 0; public: explicit BufferedStream(std::unique_ptr<Stream> inner) : inner_(std::move(inner)) {} size_t write(const char* buffer, size_t size) override { // 简化：先填充cache，满了一次性刷给inner_ size_t written = 0; while (written < size) { size_t n = std::min(size - written, cache_.size() - cache_pos_); std::memcpy(cache_.data() + cache_pos_, buffer + written, n); cache_pos_ += n; written += n; if (cache_pos_ == cache_.size()) { inner_->write(cache_.data(), cache_pos_); cache_pos_ = 0; } } return written; } };构造一条装饰链也直观：
auto stream = std::make_unique<BufferedStream>( std::make_unique<FileStream>("data.bin")); stream->write("hello", 5);这里的关键是所有权模型：每一层用unique_ptr持有内层对象，链上的销毁顺序自动从外到内，不会出现悬垂引用。很多初版代码用的是裸指针Stream* inner，析构时都不知道该不该delete，三层以上基本失控。我强烈建议不要在装饰器链上使用裸指针，用unique_ptr让编译器帮你约束所有权。
2.2 菱形继承、拷贝控制、析构顺序三个绕不开的坑
第一个坑是菱形继承。假设FileStream不仅想被装饰成流，还想被装饰成文件系统对象，比如需要并列继承Stream和FileSystemObject两个基类。此时如果两个基类又都继承自某个公共基类，菱形就出现了。处理办法是虚继承，但虚基类的构造顺序和对象布局都变得更复杂，为了装饰功能搞成这样有些得不偿失。我的建议是：保持装饰器只围绕一个接口展开，不要试图同时装饰多个维度。
第二个坑是拷贝控制。C++默认会为装饰器生成拷贝构造函数，但它拷贝的是指针或unique_ptr。如果持裸指针，拷贝后两个装饰器指向同一个内层对象，析构时会双重释放；如果持unique_ptr，拷贝构造会被编译器删除，反而安全。所以我会特意让装饰器不可拷贝，要么删除拷贝函数，要么直接用unique_ptr成员让编译器“被动删除”。
第三个坑是析构顺序，这个最隐蔽。比如BufferedStream析构时想把缓存里还没刷完的数据写回内层文件流，但C++的析构顺序是反着来的：外层装饰器先析构，内层对象后析构。如果你在BufferedStream的析构函数里调用了inner_->write(...)，而inner_指向的对象此时还没销毁，那没问题；但如果你把inner_的释放动作放在外层析构之后，比如某个成员对象先析构了还访问它，就崩了。实际的解决方案有两种：一种是装饰器析构函数只释放自己的资源，不访问内层；另一种是提供一个显式的close()方法负责刷新数据，析构函数只做最终兜底。
2.3 什么场景下还值得用继承式
虽然坑多，但继承式在简单场景下依然够用。比如数据流加解密：启动时根据配置决定是普通文件流还是压缩加密流，装饰层数固定，运行期不需要动态换装，用继承式最直白。它最大的问题不在可用性，而在扩展性——一旦装饰层多了，类层次膨胀、调试不便、构造链变长，这些痛点会催促你换到函数式或模板式方案。
3. 函数式装饰器：用std::function把接口包装成职责链
3.1 核心思想：装饰器是接收函数并返回函数的函数
很多业务场景并不需要装饰“一个对象的全部方法”，只需要装饰“某个关键动作”，比如处理一个请求、执行一个命令、根据key查询一个数据。这种情况下，与其维护一整套类继承体系，不如直接面向函数签名做装饰。
定义一个回调类型：
using Handler = std::function<Response(const Request&)>;装饰器就是一个函数，接收一个Handler，返回一个新的Handler：
Handler make_logging(Handler next, Logger* logger) { return [next = std::move(next), logger](const Request& req) -> Response { auto started = std::chrono::steady_clock::now(); try { Response resp = next(req); logger->log(req, resp, elapsed(started)); return resp; } catch (...) { logger->log_exception(req, std::current_exception(), elapsed(started)); throw; } }; }lambda捕获列表里直接next = std::move(next)，把下一层处理函数移入新lambda，避免拷贝开销。这是函数式装饰器比继承式清爽的地方——没有复杂的类层次，每个装饰器是独立函数，可以单独单测，也可以动态组合。
3.2 一条完整链路：缓存、鉴权、日志的组合
用一个具体需求串起来。假设base_handler是真正的业务函数，外面依次包缓存、鉴权、日志三层。注意组合顺序决定了实际执行顺序，构造时从里往外写：
Handler base_handler = [](const Request& req) -> Response { return compute_business_result(req); }; Handler make_cache(Handler next) { auto cache = std::make_shared<Cache>(std::chrono::seconds(60), 4096); return [next = std::move(next), cache](const Request& req) -> Response { CacheKey key = req.cache_key(); if (auto hit = cache->get(key)) { return *hit; } Response resp = next(req); cache->put(key, resp); return resp; }; } Handler make_auth(Handler next) { return [next = std::move(next)](const Request& req) -> Response { if (!req.has_permission()) { throw PermissionDenied("no permission"); } return next(req); }; } Handler pipeline = make_logging( make_auth( make_cache(base_handler)), &logger); Response resp = pipeline(req);这里每一层装饰器的入参和出参都保持相同的函数签名，这就是装饰器能在C++里用函数式方式跑起来的前提。组合出来的pipeline就是一个新的Handler，可以继续被其他装饰器包装，也可以直接传给框架层。
3.3 洋葱模型的执行顺序与调试技巧
这个结构天然是洋葱模型。make_logging是最外层，执行时先进入日志函数，记录开始时间；然后调用make_auth产生的lambda，鉴权通过后才进入make_cache；缓存未命中才最终落到base_handler。返回值再一层层返回，最后日志函数记录总耗时。所以装饰器的执行顺序和构造顺序是反的：先构造的在最外层，最后执行完。
很多人在这个环节犯的错是构造顺序写反。如果先make_cache(make_logging(...))，那么日志在缓存里面，缓存命中时根本打不到日志，排查问题时日志缺失，表现为“有些请求不知道从哪里来的”。我的调试手段是给每个装饰器加一个进入/退出的RAII日志，并带上请求关联ID：
struct ScopeLog { Json::Value context; std::string name; ScopeLog(const char* n, int64_t trace_id) : name(n) { LOG(INFO) << "[" << trace_id << "] enter " << name; } ~ScopeLog() { LOG(INFO) << "[" << trace_id << "] leave " << name; } };这样压测时随便抓一个trace_id，就能看到请求实际经过了哪些层、每层耗时多少。
3.4 std::function的开销大概是多少
std::function内部做一次类型擦除，小对象有SBO（小对象优化）避免堆分配，但带捕获列表的lambda有时会触发堆分配。一次std::function调用比裸函数指针慢几十纳秒量级，对于IO密集、业务处理动辄几毫秒的场景来说可以忽略；但如果是在一个每秒调用数百万次的循环里做装饰，这个开销就不能忽视了。那种地方要么改用模板方案，要么干脆手写函数指针链。
还有一个容易被忽略的坑：如果装饰器链被复制，std::function会被整体复制，捕获的lambda以及lambda内部捕获的shared_ptr引用计数会一起增加。这在单线程下通常没问题，但在并发环境下如果多个线程持有了同一个Handler对象的不同副本，状态共享的语义会变得微妙。需要明确的是，装饰器链对象本身建议只构造一次，通过引用或共享指针传给调用方，不要频繁拷贝。
4. 模板装饰器：把组合阶段搬到编译期
4.1 层叠式模板的基本形态
如果装饰链在编译期完全已知，就不需要std::function的类型擦除，也不需要虚函数的动态分发，可以把装饰过程全部展开到编译期。一个非常简洁的形态是：每个装饰层是一个模板类，模板参数Next是下一层的类型，内部直接持有一个Next成员。
template<typename Next> struct AccessLogLayer { Next next; Logger* logger; template<typename... Args> explicit AccessLogLayer(Args&&... args) : next(std::forward<Args>(args)...) {} Response execute(const Request& req) { auto started = std::chrono::steady_clock::now(); Response resp = next.execute(req); logger->log(req, resp, elapsed(started)); return resp; } }; template<typename Next> struct AuthLayer { Next next; std::string secret; template<typename... Args> explicit AuthLayer(Args&&... args) : next(std::forward<Args>(args)...) {} Response execute(const Request& req) { if (!req.verify(secret)) { throw PermissionDenied("invalid signature"); } return next.execute(req); } }; struct BaseHandler { Response execute(const Request& req) { return compute_business_result(req); } };组合方式：
using Pipeline = AccessLogLayer<AuthLayer<BaseHandler>>; AuthLayer<BaseHandler> auth_layer{BaseHandler{}, "secret"}; AccessLogLayer<decltype(auth_layer)> pipeline{std::move(auth_layer), &logger}; Response resp = pipeline.execute(req);这里每一层都有一个execute方法，模板化的Next在编译期被解析成具体类型，所有调用都被内联展开，没有虚函数跳转，也没有std::function的类型擦除。编译器和优化器可以跨层做常量传播、分支预测优化，极端情况下整条链可以优化成一条直线代码。
4.2 用concepts约束装饰层接口
模板参数太自由，也容易写歪。C++20的concepts可以给装饰层加上约束，要求Next类型必须具备可调用的execute方法：
template<typename T> concept Executable = requires(T& t, const Request& req) { { t.execute(req) } -> std::convertible_to<Response>; }; template<Executable Next> struct AccessLogLayer { ... };这样一旦有人把BaseHandler错写成一个没有execute方法的类型，编译错误会直接指向概念约束，而不是报一长串模板实例化信息。这让模板装饰器在团队协作时更容易维护。
4.3 编译期方案的代价与适用边界
编译期方案最大的限制是：装饰层的组合必须在编译期确定。如果你要根据配置文件决定是否开启缓存、是否做鉴权、是否打日志，模板方案就非常笨拙——你要为每一种组合实例化一套类型，然后写分支去构造。这不但让二进制膨胀，还让逻辑变得分散。
另一个代价是编译错误和调试体验。嵌套模板一旦出错，编译器的报错可能长达几十行，需要一层层剥开看。调试器里看到的也是模板实例化后的类型名，栈非常深。我建议用“辅助构造函数”或者make_layer函数简化实例化过程。
我的选型经验是：
- 框架内部的基础设施，比如RPC过滤链、网络协议栈处理，装饰层写死且要极高性能时，用模板。
- 业务层的可配置中间件，比如按产品配置决定日志开关、限流开关、缓存开关，用
std::function方案。
5. 三个生产级案例：缓存、重试、事务边界
5.1 缓存装饰器：缓存键设计比想象中重要
给查询用户详情的Handler加缓存是常见需求。代码可以直接复用上面的make_cache。但在实际项目里，最容易出问题的不是缓存本身，而是缓存键。
如果你直接用整个Request对象做hash，而这个对象里含有traceId、时间戳等随机字段，那么每次请求的key都不同，缓存永远不命中，等于白包。正确做法是让业务显式提供一个cache_key()方法，只取业务语义上决定结果唯一的字段。比如用户详情查询，key就是user_id。
第二个坑是缓存穿透。如果缓存里没有某条数据，每次查询都会直接打到数据库。尤其是在用户传一个不存在的user_id时，缓存永远miss，DB被反复压。解决办法是空值缓存：把“查不到”的结果也写入缓存，TTL设短一些，比如10秒，扛住瞬时攻击流量。有些场景还会配合布隆过滤器，先把不存在的id挡在外面。
第三个坑是并发下的缓存击穿。某个热点key过期，瞬间有100个相同请求进来，都会穿透到DB。朴素做法是加锁，但会阻塞无key竞争。更好的做法是使用“单飞”结构，把相同key的并发请求合并成一次DB查询。C++实现单飞需要std::mutex、std::condition_variable和std::future配合，代码量不小但效果立竿见影。
5.2 重试装饰器：重试不是免费的
下游RPC偶发超时，给Handler包一层重试逻辑，这个需求也很常见。我用一个简化版本：
Handler make_retry(Handler next, int max_attempts) { return [next = std::move(next), max_attempts](const Request& req) -> Response { for (int attempt = 1; ; ++attempt) { try { return next(req); } catch (const RetriableError&) { if (attempt >= max_attempts) { throw; } auto delay = std::chrono::milliseconds(50 * (1 << (attempt - 1))); std::this_thread::sleep_for(delay); } } }; }这里有两个生产级别的坑。
第一个坑是重试只在接口幂等时才安全。如果下游接口不幂等，比如“创建订单”接口，网络超时后服务端可能已经创建成功，客户端重试就会创建重复订单。所以重试装饰器通常只用于GET类查询接口，或者要求下游提供幂等键。在你没有把握的情况下，宁可把重试次数配置为0，也不要默认开启重试。
第二个坑是退避策略要加随机抖动。如果一批请求在同一时刻超时，不抖动的指数退避会让它们在下一个时间点同时重试，打爆下游。我习惯在计算出的delay上叠加一个random(0, 50ms)的扰动，让重试请求散开。
还要注意，重试装饰器和缓存装饰器同时出现时要格外小心。如果缓存层捕获了错误结果并写入缓存（比如把超时异常包装成一个空的Response），重试逻辑就永远不会被触发，因为每次请求都从缓存命中“错误结果”。我建议明确约定：缓存层只缓存成功结果，一切异常都往上层抛。
5.3 事务装饰器：把异常传播方向理顺
数据库操作需要事务边界。用模板式装饰器实现事务层是最自然的，因为事务的“开始、提交、回滚”非常适合RAII：
template<typename Next> struct TransactionalLayer { Next next; template<typename... Args> explicit TransactionalLayer(Args&&... args) : next(std::forward<Args>(args)...) {} void execute(Context& ctx) { auto tx = ctx.db().begin(); try { next.execute(ctx); tx.commit(); } catch (...) { tx.rollback(); throw; } } };核心是catch块里必须rollback()之后重新throw，把异常继续往上层抛。我踩过一个很深的坑：早期版本在catch块里写return;，把异常吞掉了。结果调用方以为执行成功，继续往下走，实际数据已经回滚，整个业务流程变得半死不活。后来我改用RAII事务管理器，把commit放在析构函数里只有显式commit()才置标志位，析构时未提交则自动回滚，从机制上杜绝了“忘了rollback”的问题。
事务边界的另一层问题是大事务嵌套。如果两个服务互相调用，每个服务各开一个事务，就会出现同一条链路上有两个事务边界。由于数据库连接通常是线程绑定的，第二个事务会复用同一个连接，导致内层提交把外层事务的一部分数据也提交了，外层再想整体回滚就不彻底。解决方法是使用连接池的“事务上下文”管理，把事务边界提升到最外层调用方，内层只做SQL操作，不重复begin。
6. 装饰器实践中的生命周期、线程安全与调试手段
6.1 持有关系怎么设计才算稳
不同方案的持有关系有不同设计。继承式装饰器链建议全部用unique_ptr单向持有下一层，销毁时自动从外到内释放。函数式装饰器链中，被捕获的共享状态用shared_ptr，链入口用std::function整体持有。模板装饰器层与层之间是值成员，随外层对象一起构造析构，最省心。
无论哪种方案，都要避免装饰器存指向栈上临时对象的裸引用。你看make_logging(Handler next, Logger* logger)里的logger，如果调用方传入的Logger是栈对象，而pipeline活得更久，回调触发时就是悬垂引用。我的经验是所有跨线程使用的装饰器状态，一律用shared_ptr传入并在lambda里捕获shared_ptr，保证引用计数不为零。
6.2 装饰器是否线程安全，关键看状态放在哪
无状态装饰器天然线程安全，多个线程同时调用同一个Handler没问题。麻烦的是有状态装饰器，比如缓存、计数、限流。一旦某个装饰器内部有unordered_map之类的共享可变状态，整条装饰链就变成有状态的了。
我项目里一个真实教训：一个缓存装饰器内部用unordered_map存KV，压测前没加锁，4线程并发直接数据竞争崩溃。后来改成std::mutex+双检查锁定，命中路径只读map，没有锁竞争；未命中才加锁并回填缓存。压测数据从崩溃变成稳定，但吞吐比无锁版本低了一截。如果你对性能极其敏感，可以用无锁哈希表或者分片锁，但复杂度会明显上升。
另一个点是整个装饰链由多个线程共享时，如果最外层不是线程安全的，内层再安全也没用。所以线上系统里，我更倾向于把装饰链的调用入口设计成“每个请求线程持有自己的调用上下文，装饰器链本身只读共享”，这样大部分装饰器都能做成无状态，只在需要的地方显式加锁。
6.3 调试手段：把调用链变得“所见即所得”
装饰器一多，gdb断点会一层层跳，崩溃栈满屏模板实例。我常用的手段有三个：
第一是给每个装饰器起一个name字段，在日志里输出当前层名。函数式方案在lambda里捕获一个字符串常量即可，模板方案可以定义一个静态constexpr const char* name。
第二是RAII日志记录进入/退出，配合trace_id串起整个请求。多线程并发时，按trace_id过滤日志就能还原每个请求走了哪些层、每层耗时多少、哪一层抛了异常。没有这套日志，靠脑子推洋葱层级关系很容易出错。
第三是给模板装饰器提供static_assert级别的能力检查，比如static_assert(Executable<Next>)，让不符合要求的用法在编译期就暴露，而不是到运行期才莫名崩溃。
6.4 装饰器不是万能药：什么时候该收手
装饰器模式的核心价值是“在原有行为外动态附加职责”，但它不是银弹。如果一个装饰器内部塞了一大堆互不相关的逻辑，比如既要打印日志又要做权限校验又要统计指标，说明这个装饰器该拆了。装饰器应该是单一职责的，一层只做一件事。
如果一条调用链超过五六层，层级顺序还经常变，装饰器嵌套的可读性会急剧下降。这时候我建议改造成显式的中间件管线：用一个std::vector<std::unique_ptr<Middleware>>保存所有中间件，按顺序迭代执行，中间件之间通过一个next函数指针传递控制权。这样中间件的增删、排序、替换都可以配置化，比装饰器嵌套更直观。
还有一个容易和装饰器混淆的是策略模式。装饰器是在原有行为外加一层行为，策略模式则是替换行为实现。如果你发现自己在写“跳过某个装饰器”或者“禁用某个装饰器”，可以考虑改用策略模式，把“是否启用”变成策略选择。否则装饰器链会越包越长，最后难以维护。
从第一次写崩裸指针装饰链，到后来形成“所有权明确、状态分离、可观测”的实践，我在这个模式上走了不少弯路。现在的习惯是：先在脑里回答三个问题——谁拥有装饰链对象？多个线程是否共享有状态装饰器？装饰层顺序是否需要运行期可调？把这三点想清楚，再动手写代码，基本不会再遇到那种“线上跑得好好的，某次压测突然崩了”的事故。如果你正在重构类似的消息处理或接口调用功能，不妨先写几个小原型，把缓存未命中、重试耗尽、事务回滚、并发调用这几个边界场景用单测覆盖住，再往核心业务里铺开。
