C++装饰器模式三种落地变体：继承、模板与函数式-平芜编程栈

聊到 C++ 里的装饰器模式，我先说结论：它从未从 C++ 身上离开，只是常常不叫这个名字。很多项目里常见的日志钩子、鉴权包装、请求重试，都是把装饰器模式改头换面后在用。我见过有人为了一段重试逻辑改动核心服务类的构造函数，也见过有人因为包装对象的生命周期没处理好，在 Windows 上报出 Access Violation，调试了整整两天。这篇文章想做的，就是把装饰器模式在 C++ 里的几种真实变体掰开揉碎，结合实际代码聊一聊。

在 GoF 的经典书里，装饰器模式（Decorator）是给对象动态添加职责、同时保持接口透明的模式。经典形态当然有效，但 C++ 是门多范式语言，同一个“包装一层”的思想，落地时至少有三种常见玩法：继承式运行时装饰器、模板或 CRTP 风格的编译期装饰器、以及基于std::function和 lambda 的函数式装饰器。这三者各有各的使用场景，也各有各的坑。这篇文章适合两类人：一类是刚接触设计模式、想在 C++ 里把概念落到实处的同学；另一类是在老项目里做横切能力扩展，被“加日志、加重试、加缓存”这类需求反复折磨的工程师。我会把真实踩过的坑一并写出来。

1. 装饰器模式到底在解决什么问题

1.1 把扩展逻辑从业务代码里剥出来

装饰器模式的核心思想很简单：不改动原始对象，而是用一个接口相同的新对象把原始对象包起来，在调用原始方法的前后或者正常流程里插入自己的逻辑。听上去和代理模式很像，两者的区别在于意图。代理模式强调控制访问，比如权限校验、懒加载、远程调用；装饰器模式强调增强功能，比如加日志、加缓存、加压缩。你完全可以在实现上写出结构相同的代码，但命名和设计意图会直接影响后续维护者怎么理解它。

我最喜欢用的一个生活化类比是手机壳。手机本身能打电话、能刷应用，但套上一个带支架的壳，就多了个支撑功能；套上防摔壳，又多了保护功能。壳不会改手机，也不会要求手机为它做出任何修改。装饰器模式在代码里的价值也是一样的：当你想给“查询订单价格”这个方法加上缓存，又不想把缓存逻辑写成十几行嵌套在业务代码里时，就可以在外层套一个CachedPriceQuery。业务层完全无感，测试依然可以只盯着原始类，横切逻辑则独立维护。

这个模式很擅长解决横切关注点。日志、性能统计、重试、缓存、输入校验、数据压缩，这些逻辑有一个共同点：它们不关心业务到底怎么算，只关心在调用发生的前后做什么。把它们放进业务方法里，会让核心逻辑被淹没；把它们抽到装饰器里，则可以让核心类保持干净，也方便不同装饰器随意组合。比如文件读写，我能写一个FileDataSource，再写一个CompressDecorator，最后写一个EncryptDecorator，然后按Encrypt(Compress(File))的顺序组合，想调整组合顺序时根本不用去改那三个类。

1.2 经典装饰器的 C++ 落地差异

GoF 里的装饰器图通常是三层：抽象组件接口、具体组件实现、装饰器基类。这个模型在 Java 和 C# 里非常顺，因为两者的对象默认都是引用语义，你包一层、传一个引用，几乎没有生命周期负担。C++ 则完全不同，值语义、所有权管理、虚函数开销，这些都会在经典实现里冒出来。

第一个麻烦是所有权。装饰器里通常会持有下一个组件的指针。如果这个指针是裸指针，调用方就得保证它活得比装饰器久。一旦有人把一个栈对象塞进装饰器，然后在函数返回后再去调用它，轻则拿到垃圾数据，重则直接崩溃。在 Windows 上很容易看到c0000005也就是 Access Violation。第二个麻烦是切片问题。如果装饰器按值存储组件对象，virtual特性立刻失效，因为切片会把子类对象砍成基类对象。解决方式要么用指针，要么把装饰器本身定义成模板，按值存储且保留原类型。第三个麻烦是虚函数本身的成本。虽然单次虚函数调用多一次间接跳转并不夸张，但装饰器一旦套了四五层，每一层多一次间接调用，在一些高频热路径上积累起来就很可观。

所以 C++ 里的装饰器模式，从来不是只有一个标准答案。你需要在可维护性和性能之间做取舍，在运行时动态和编译期静态之间做取舍。接下来这三节，就是我从项目里筛出来的三种最实用变体。

2. 三种实用的 C++ 装饰器变体

2.1 继承式运行时装饰器：最保守也最通用

先写最经典的一版。假设我们有一个数据源接口，要给它加压缩能力。

#include <memory> #include <string> #include <utility> class DataSource { public: virtual ~DataSource() = default; virtual void writeData(const std::string& data) = 0; virtual std::string readData() = 0; }; class FileDataSource final : public DataSource { public: explicit FileDataSource(std::string path) : path_(std::move(path)) {} void writeData(const std::string& data) override { // 真实实现里会打开文件并写入 } std::string readData() override { return {}; // 真实实现里会从文件读取 } private: std::string path_; }; class DataSourceDecorator : public DataSource { protected: explicit DataSourceDecorator(std::unique_ptr<DataSource> next) : next_(std::move(next)) {} std::unique_ptr<DataSource> next_; }; class CompressDecorator final : public DataSourceDecorator { public: using DataSourceDecorator::DataSourceDecorator; void writeData(const std::string& data) override { auto compressed = compress(data); next_->writeData(compressed); } std::string readData() override { auto data = next_->readData(); return decompress(data); } private: std::string compress(const std::string& s) const { return s; } std::string decompress(const std::string& s) const { return s; } }; class EncryptDecorator final : public DataSourceDecorator { public: using DataSourceDecorator::DataSourceDecorator; void writeData(const std::string& data) override { auto encrypted = encrypt(data); next_->writeData(encrypted); } std::string readData() override { auto data = next_->readData(); return decrypt(data); } private: std::string encrypt(const std::string& s) const { return s; } std::string decrypt(const std::string& s) const { return s; } };

组合方式非常直白：

auto source = std::make_unique<EncryptDecorator>( std::make_unique<CompressDecorator>( std::make_unique<FileDataSource>("orders.dat")));

这个变体的最大优点是透明。调用方只看到DataSource，完全不知道里面套了几层，以后加一层缓存装饰器也不用动调用方代码。维护上最需要注意的是两条铁律：第一，基类析构函数必须是virtual，否则通过unique_ptr<DataSource>删除派生的EncryptDecorator时，派生类析构函数不会被调用，资源释放就可能出问题。第二，组件对象的所有权一定要明确。用unique_ptr就是表示“装饰器独占这份资源”，用shared_ptr就是表示“多个装饰器共享同一个底层对象”，绝不能一个裸指针在不同层之间来回传。

这种变体适合的场景是运行时组合、类型稳定、装饰器种类可以继续扩展。例如插件系统里，用户在配置文件中写“启用压缩、启用加密”，程序在启动时动态拼装对象。缺点是虚函数调用和对象分配会带来一点开销，而且一旦嵌套层级深，调用栈会变得难看，调试时经常要在 IDE 里一层层往下点。

2.2 模板与 CRTP 风格的编译期装饰器

如果装饰器的组合关系在编译期就确定，而且你希望把运行时开销压到零，就可以使用模板风格的变体。这种写法本质上是一种混入（mixin），通过继承把行为贴到目标类上，类型在编译期就完整展开。

#include <chrono> #include <iostream> struct Worker { void run() { std::cout << "worker run\n"; } }; template<typename Base> class TimingDecorator : public Base { public: using Base::Base; void run() { auto start = std::chrono::steady_clock::now(); Base::run(); auto end = std::chrono::steady_clock::now(); std::cout << "elapsed: " << std::chrono::duration_cast<std::chrono::microseconds>( end - start).count() << "us\n"; } };

使用起来很直接：TimingDecorator<Worker> timedWorker; timedWorker.run();。

这里的TimingDecorator在概念上就是一个装饰器：它在不修改Worker的前提下，给run增加了计时能力。但因为组合发生在模板实例化时，整个调用链最终会内联展开，不会出现虚函数表查询和跨层间接调用。如果Base::run()本身不是虚函数，编译器甚至能把TimingDecorator<Worker>::run优化成一段完全直线型的代码。

要注意，这种变体并不是“经典意义的装饰器”。经典装饰器要求装饰后的对象还能以原接口的类型出现，比如继续放进vector<unique_ptr<DataSource>>里，但TimingDecorator<Worker>就是一个全新的类型，它和Worker之间没有多态关系。因此它更适合静态调用链的场景：比如 SDK 内部，某个固定的算法流水线需要套日志和性能统计，但对外并不需要暴露统一接口。它的另一个风险点是，如果混用虚函数，模板装饰器在继承层级里叠加会变得很绕。我一般建议把它当作“编译期增强器”来理解，不要强行往 GoF 装饰器框架里硬套。

2.3 函数式装饰器：包装可调用对象与回调

C++ 和 Java 的一个很大不同，就是 C++ 不仅有对象，还有一等公民的函数对象。装饰器模式完全可以直接作用在函数层面：输入一个可调用对象，输出另一个可调用对象。这就构成了第三种变体，也是我在现代 C++ 项目里用得最多的一种，因为它写起来最轻，也不需要引入庞大的类继承体系。

下面的代码给任意函数加计时能力：

#include <chrono> #include <functional> #include <iostream> #include <type_traits> #include <utility> template<typename Fn> auto withTiming(Fn&& fn) { return [fn = std::forward<Fn>(fn)](auto&&... args) { auto start = std::chrono::steady_clock::now(); if constexpr (std::is_void_v< std::invoke_result_t<Fn&, decltype(args)...>>) { fn(std::forward<decltype(args)>(args)...); auto end = std::chrono::steady_clock::now(); std::cout << "elapsed: " << std::chrono::duration_cast< std::chrono::microseconds>(end - start).count() << "us\n"; } else { auto result = fn(std::forward<decltype(args)>(args)...); auto end = std::chrono::steady_clock::now(); std::cout << "elapsed: " << std::chrono::duration_cast< std::chrono::microseconds>(end - start).count() << "us\n"; return result; } }; } void sendMessage(const std::string& msg) { // 模拟耗时操作 std::cout << "send: " << msg << "\n"; } int main() { auto timedSend = withTiming(sendMessage); timedSend("hello decorator"); }

这段代码巧妙的地方在于，lambda 按值捕获了传入的fn，然后对外提供operator()。调用者拿着timedSend就和拿着原始函数一样，只是每次调用都会自动记录时间。

函数式装饰器有几个关键细节。第一，捕获方式很重要。我把fn按值捕获，这样withTiming返回之后，原始函数对象仍然被安全持有。如果捕获的是引用，一旦原变量离开作用域，lambda 就悬空了，这也是生成Access Violation的常见来源。第二，需要用mutable吗？不一定，只有装饰器内部状态需要在调用之间改变时才需要。比如实现一个带计数功能的装饰器，就要写mutable。第三，泛型调用参数auto&&... args配合std::forward是为了保持参数的左值/右值属性，避免无谓拷贝。第四，如果被包装的函数返回类型是void，你没法在这段代码里直接定义auto result = fn(...)，所以要先用if constexpr分流出 void 的情况。

这个变体和回调的关系非常紧密。传统 C 风格回调通常是一个裸函数指针加一个void*上下文，而 C++ 的风格是std::function或泛型 lambda。装饰器可以包装std::function，比如下面这种写法：

std::function<int(int)> original = [](int x) { return x * 2; }; auto decorated = withTiming(original); int y = decorated(21); // 返回 42，同时输出耗时

std::function本身在内部做了类型擦除，捕获了一个可调用对象，所以它可以在运行时被替换、保存到容器里，甚至作为回调传递给异步接口。缺点也很明显：std::function调用时可能包含类型擦除开销，如果可调用对象超过其内部缓冲区大小，还会引发堆分配。因此函数式装饰器里，我建议在接口边界或容器场景用std::function，在单点调用场景直接用泛型 lambda 模板，不要在一开始就把一切包装成std::function。

3. 实操：搭一个可复用的“重试+日志”装饰器

3.1 需求拆解：先决定用哪种变体

理论说得再多，不如直接构造一个实际需求。假设我们有一个fetchPrice函数，向行情服务发起 HTTP 请求，偶发超时。现在需要给它加上两件事：失败时自动重试三次；调用前和调用后分别输出日志。最朴素的做法是改函数内部，把重试循环和日志混进业务代码里。但如果我们还有其他函数也要重试，或者未来想调整重试次数，这种写法会迅速发散。

更合理的思路是先判断项目形态。如果fetchPrice是一个自由函数，周围有十几个类似函数都要做相同的横切增强，那么函数式装饰器最合适，因为它们以组合子形式存在，可以像叠积木一样套用。如果项目里fetchPrice是一个继承体系中的虚方法，下面有HttpPriceService、MockPriceService等多个实现，那么继承式运行时装饰器更合适，因为调用方持有的是接口指针，你可以在运行时装载装饰器而不改调用点。这两种选择不是互斥的，同一个项目里完全可以混用。

我先把需求拆分清楚。重试装饰器要做的职责是：调用被包裹的函数；如果抛出指定异常，等待一小段时间后重新调用；达到最大次数后继续抛出。日志装饰器要做的职责是：调用前打印入参摘要；调用后打印返回值或异常信息，顺带记录耗时。两者都是横切关注点，给它俩起个名字withRetry和withLogging，然后把它们组合起来。

3.2 先写函数式版本，把组合做到极致

下面这段是可用的重试装饰器：

#include <chrono> #include <exception> #include <stdexcept> #include <thread> #include <utility> template<typename Fn> auto withRetry(Fn&& fn, int times) { return [fn = std::forward<Fn>(fn), times](auto&&... args) { for (int attempt = 0; attempt < times; ++attempt) { try { return fn(std::forward<decltype(args)>(args)...); } catch (const std::exception&) { if (attempt + 1 == times) { throw; } std::this_thread::sleep_for(std::chrono::milliseconds(100)); } } throw std::logic_error("unreachable"); }; }

有几个点值得解释。为什么在 lambda 里声明局部变量attempt，而不是声明一个捕获变量？因为每次调用都应该从 0 开始计数，用[times]按值捕获times，在函数体内维护状态即可，lambda 本身不需要mutable。为什么捕获fn按值？为了保证包装出来的新可调用对象拥有独立的函数副本，这样withRetry返回之后，原函数即使被销毁，新的调用仍然安全。为什么throw放在 for 循环后？循环逻辑保证attempt走到times时必然已经抛出或被 return，所以这个抛出只是兜底，用来让编译器开心，以防遗漏返回路径。

接下来是日志装饰器，权且把日志打到标准输出：

#include <chrono> #include <iostream> #include <type_traits> #include <utility> template<typename Fn> auto withLogging(Fn&& fn, const char* name) { return [fn = std::forward<Fn>(fn), name](auto&&... args) { std::cout << "[call] " << name << " begin\n"; auto start = std::chrono::steady_clock::now(); if constexpr (std::is_void_v< std::invoke_result_t<Fn&, decltype(args)...>>) { fn(std::forward<decltype(args)>(args)...); auto end = std::chrono::steady_clock::now(); std::cout << "[call] " << name << " end, elapsed " << std::chrono::duration_cast< std::chrono::microseconds>(end - start).count() << "us\n"; } else { auto result = fn(std::forward<decltype(args)>(args)...); auto end = std::chrono::steady_clock::now(); std::cout << "[call] " << name << " end, result=" << result << ", elapsed " << std::chrono::duration_cast< std::chrono::microseconds>(end - start).count() << "us\n"; return result; } }; } double fetchPrice(const std::string& symbol) { if (symbol.empty()) { throw std::runtime_error("bad symbol"); } return 3.14; } int main() { auto safeFetch = withRetry(withLogging(fetchPrice, "fetchPrice"), 3); double price = safeFetch("AAPL"); std::cout << price << "\n"; }

这个组合有一个特别容易搞反的地方：withRetry(withLogging(fetchPrice, "fetchPrice"), 3)和withLogging(withRetry(fetchPrice, 3), "fetchPrice")的执行顺序完全不同。前者是外层重试、内层日志，所以每次重试之前都会打印一次begin，每次尝试失败后日志逻辑也会记录一次end，细节多但时间线清楚。后者是外层日志、内层重试，只会记录一次begin和一次end，时间跨度覆盖整个重试过程。所以“先包谁，谁就是外层”这句话，在调试时真的救过我很多次。

3.3 再写继承式版本，适配虚接口场景

如果调用方持有的是PriceService*，函数式包装器就不好使了。这时候需要回到面向对象的继承式装饰器。

#include <memory> #include <string> #include <chrono> #include <iostream> class PriceService { public: virtual ~PriceService() = default; virtual double fetchPrice(const std::string& symbol) = 0; }; class HttpPriceService final : public PriceService { public: double fetchPrice(const std::string& symbol) override { if (symbol.empty()) { throw std::runtime_error("bad symbol"); } return 42.0; } }; class PriceServiceDecorator : public PriceService { protected: explicit PriceServiceDecorator(std::shared_ptr<PriceService> next) : next_(std::move(next)) {} std::shared_ptr<PriceService> next_; }; class RetryingPriceDecorator final : public PriceServiceDecorator { public: RetryingPriceDecorator(std::shared_ptr<PriceService> next, int times) : PriceServiceDecorator(std::move(next)), times_(times) {} double fetchPrice(const std::string& symbol) override { int attempt = 0; while (true) { try { return next_->fetchPrice(symbol); } catch (const std::exception&) { if (++attempt >= times_) { throw; } std::this_thread::sleep_for(std::chrono::milliseconds(50)); } } } private: int times_; }; class LoggingPriceDecorator final : public PriceServiceDecorator { public: using PriceServiceDecorator::PriceServiceDecorator; double fetchPrice(const std::string& symbol) override { std::cout << "[log] fetchPrice begin\n"; auto start = std::chrono::steady_clock::now(); try { double result = next_->fetchPrice(symbol); auto end = std::chrono::steady_clock::now(); std::cout << "[log] fetchPrice end, result=" << result << "\n"; return result; } catch (...) { auto end = std::chrono::steady_clock::now(); std::cout << "[log] fetchPrice exception after " << std::chrono::duration_cast< std::chrono::microseconds>(end - start).count() << "us\n"; throw; } } };

使用方式：

auto service = std::make_shared<LoggingPriceDecorator>( std::make_shared<RetryingPriceDecorator>( std::make_shared<HttpPriceService>(), 3)); double price = service->fetchPrice("AAPL");

这里我特意用了shared_ptr而不是unique_ptr。原因是装饰器链中每一层都持有下一层，如果后面想把这个服务同时传给两个客户端组件，共享所有权会更方便。你当然可以用unique_ptr表达独占所有权，那就调用方给什么、装饰器就接什么，不要在里面偷偷再存一份裸指针。总的来说，只要能明确所有权，两种智能指针都行；怕就怕写着写着又退回new和裸指针“图省事”。

这个版本的另一个细节是日志装饰器里用try/catch捕获异常后记录再重新抛出。这保证了调用方拿到的异常语义和原始服务一致，同时日志信息不会丢失。我见过有人为了图方便，在装饰器里吞掉异常只返回默认值，结果把调用方的错误处理逻辑全部打乱。装饰器可以加日志、加重试，但不应该改变原始接口的失败语义，除非业务上明确要求这样做。

3.4 VSCode 下快速验证这些示例

代码写出来总得跑一遍。如果你用的是 VSCode 搭 C/C++ 开发环境，最简单的验证方式不是先配一堆复杂的构建脚本，而是直接在终端里用编译器命令跑：

g++ -std=c++17 -Wall -Wextra main.cpp -o demo ./demo

命令行能跑通，再考虑上 CMake。我一般会在项目根目录放一个最小的 CMakeLists.txt：

cmake_minimum_required(VERSION 3.16) project(decorator_demo CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(demo main.cpp)

然后在 VSCode 里安装 C/C++ 扩展和 CMake Tools 扩展，用Ctrl+Shift+P打开命令面板，选择 “CMake: Select a Kit”，把编译器指到本机的 GCC、Clang 或 Visual Studio Build Tools。这里有个我在实际配置中踩过多次的坑：如果工程路径含有中文目录名，某些 Windows 环境下的 CMake 和调试器会偶发找不到文件或断点不命中。不是百分百必现，但一旦出现，排查成本极高。我的建议是 C++ 工程一律放到纯英文路径下，省下的时间远比改路径付出的时间多。

至于代码补全和跳转，如果发现 VSCode 里所有函数和变量都没法跳转，通常不是代码本身的问题，而是没有生成compile_commands.json，C/C++ 插件失去了翻译单元索引。CMake Tools 一般会自动生成，也可以手动设置：

{ "C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools" }

保证每个源文件都知道包含路径和宏定义，跳转自然就恢复了。这个小节和装饰器模式本身无关，但我在演示这类设计模式代码时，遇到最多的环境问题就是这个，所以放在这里当个补充经验。

4. 常见崩溃、性能损耗与避坑口诀

4.1 Access Violation 是从哪里冒出来的

Windows 下最常见的 C++ 崩溃异常码就是c0000005，对应 Access Violation，意思是程序访问了不允许访问的内存地址。装饰器模式里，这个错误出现得尤为频繁，因为装饰器天然是“层层套娃”的结构，对象所有权一旦混乱，悬空指针简直防不胜防。

我这里总结三条高发原因。第一条是包装对象悬空。比如有人把栈上对象的裸地址传进装饰器：

FileDataSource fs("data.txt"); auto deco = std::make_unique<CompressDecorator>(&fs); // fs 在函数结束后销毁，但 deco 还活着

这里CompressDecorator接收的参数类型应该是unique_ptr<DataSource>，把&fs这种裸地址硬塞进去，本身就会触发编译错误，除非你显式用了unique_ptr<DataSource>(&fs)，或者偷偷改了接口设计。一旦允许裸指针进入，等到fs离开作用域而deco还在使用时，访问虚表指针或成员变量就会踩到无效内存。

第二条是缺少虚析构。基类DataSource如果没有virtual ~DataSource()，通过基类指针删除派生对象时，派生类析构逻辑不会执行。资源没有释放，后续堆状态被破坏，也许不会立刻崩，但会在某个随机时刻表现为c0000005。这是典型的延迟崩溃，特别难排查。所以继承式装饰器的基类析构函数务必写成virtual，或者至少是protected非虚析构，禁止通过基类指针删除。

第三条是跨语言边界或回调场景下的生命周期错配。如果你要在 C# 里调用 C++ 的装饰器，或者在异步回调里把std::function转成裸函数指针传给 C 接口，必须额外注意：std::function是一个 C++ 对象，直接把它转成函数指针只会得到一个错误的地址。正确做法通常是维护一个全局表，用一个整数句柄关联std::function，回调函数通过句柄找回并调用。两端如果有一端把关联对象提前释放，回调触发时就会崩出c0000005。我在实际项目里处理过好几回这种问题，最后基本都是生命周期管理问题，而不是调用约定问题。

排查这类崩溃时，工具很有用。Linux 下我优先上 AddressSanitizer，只要编译时加-fsanitize=address -g，悬空指针通常能直接定位到出错行；Windows 下用 VS 自带的检测工具或者 WinDbg 抓调用栈，也比闷头猜快得多。最重要的是，看到c0000005不要急着怀疑编译器、怀疑平台，先回头检查自己持有的对象是否还活着。

4.2 性能开销到底有多大

装饰器模式被诟病最多的一点是性能。我需要说一句公道话：经典继承式装饰器的性能开销主要来自虚函数调用和嵌套层数，但绝大多数业务系统里，这点开销根本可以忽略。你一次网络请求消耗几毫秒，装饰器多一次间接跳转消耗几纳秒，完全不在一个量级。真正要警惕的，是那些每毫秒执行几十万次的热点路径。

在热路径上，每增加一层运行时装饰器，就多一次虚函数调用。一次虚函数调用通常意味着 CPU 要去查虚函数表，再做一次间接跳转。现代 CPU 的分支预测对稳定的虚调用其实处理得不错，但如果有多种派生类型交替出现，分支预测就会失效。相比之下，模板风格的编译期装饰器因为类型在编译期确定，编译器可以做内联，甚至可以把整个装饰链优化成一段线性指令。std::function的代价则取决于内部缓冲区能否容纳捕获对象：现代实现通常有 small buffer optimization，带入std::function的裸函数指针或无捕获 lambda 不需要堆分配，但如果捕获一个大对象，就会触发堆分配和拷贝。

我把三种变体的取舍列成一张速查表，方便你决策：

变体类型	运行时开销	组合灵活性	类型透明性	适用场景
继承式运行时装饰器	每层一次虚函数调用，可能有一次堆分配	高，可在运行时动态组合	高，调用方只看基类接口	插件系统、可配置流水线、跨接口调用
模板/CRTP 编译期装饰器	极低，可内联，零虚表开销	低，组合关系在编译期固定	低，装饰后是全新类型	固定流水线、SDK 内部增强、高频调用
函数式 lambda 装饰器	取决于实现方式，可能产生额外拷贝	高，装饰器也是可组合函数	中，返回新的可调用对象	回调、异步任务、自由函数横切逻辑

如果你在做性能敏感模块，建议先用编译器输出看汇编。GCC 可以用-O2 -S，Clang 可以用-S -emit-llvm，检查装饰后是否真的内联了。不要凭感觉认定“多态就慢”，也不要因为模板听起来高端就强行把所有逻辑都用模板压平。可维护性和性能要放在项目真实背景下权衡。

4.3 常见问题速查表

下面的表格是我平时排查装饰器问题时习惯对照的速查内容，也分享给读者。每一条我都实际遇到过，不是凭空总结。

现象	可能原因	处理方式
调用装饰后的对象时崩溃`c0000005`	底层对象悬空、基类缺少虚析构、裸指针被智能指针多次释放	检查所有权；基类析构加`virtual`；统一用`unique_ptr`或`shared_ptr`管理
日志或重试顺序和预期不一致	装饰器组合顺序理解错	记住外层装饰器的 before 先执行，after 后执行；用`withA(withB(fn))`表示 A 在外层
用了函数式装饰器后编译报类型错误	lambda 的返回类型在 if/else 分支中推导不出统一类型	给 lambda 明确返回类型；检查 void 分支是否被`if constexpr`隔离
`std::function`装饰链性能下降	捕获大对象导致堆分配，或频繁拷贝	换用模板参数接收可调用对象，延迟到调用点再擦除类型
VSCode 中函数变量无法跳转	缺少`compile_commands.json`或配置提供器未设置	用 CMake Tools 生成索引，并把`C_Cpp.default.configurationProvider`指过去
调用 C 接口时函数指针失效	`std::function`被当成裸函数指针使用	用全局注册表 + 整数句柄桥接，确保可调用对象生命周期覆盖整个回调过程

这些问题的共性，归根结底是“生命周期”和“类型理解”两个词。装饰器模式本身不难，真正让项目翻车的从来都是包在外层的那些间接层所引入的隐性复杂度。我现在的习惯是，一个模块如果装饰器超过三层，就单独写一个组合工厂函数，把嵌套顺序和生命周期封装进去，像这样：

std::unique_ptr<PriceService> buildOrderService() { return std::make_unique<LoggingPriceDecorator>( std::make_unique<RetryingPriceDecorator>( std::make_unique<HttpPriceService>(), 3)); }

这样既能享受装饰器的灵活组合，又不会让调用点被一串嵌套构造函数淹没。