聊到 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_ptrDataSource next) : next_(std::move(next)) {} std::unique_ptrDataSource 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_uniqueEncryptDecorator( std::make_uniqueCompressDecorator( std::make_uniqueFileDataSource(orders.dat)));这个变体的最大优点是透明。调用方只看到DataSource完全不知道里面套了几层以后加一层缓存装饰器也不用动调用方代码。维护上最需要注意的是两条铁律第一基类析构函数必须是virtual否则通过unique_ptrDataSource删除派生的EncryptDecorator时派生类析构函数不会被调用资源释放就可能出问题。第二组件对象的所有权一定要明确。用unique_ptr就是表示“装饰器独占这份资源”用shared_ptr就是表示“多个装饰器共享同一个底层对象”绝不能一个裸指针在不同层之间来回传。这种变体适合的场景是运行时组合、类型稳定、装饰器种类可以继续扩展。例如插件系统里用户在配置文件中写“启用压缩、启用加密”程序在启动时动态拼装对象。缺点是虚函数调用和对象分配会带来一点开销而且一旦嵌套层级深调用栈会变得难看调试时经常要在 IDE 里一层层往下点。2.2 模板与 CRTP 风格的编译期装饰器如果装饰器的组合关系在编译期就确定而且你希望把运行时开销压到零就可以使用模板风格的变体。这种写法本质上是一种混入mixin通过继承把行为贴到目标类上类型在编译期就完整展开。#include chrono #include iostream struct Worker { void run() { std::cout worker run\n; } }; templatetypename 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_caststd::chrono::microseconds( end - start).count() us\n; } };使用起来很直接TimingDecoratorWorker timedWorker; timedWorker.run();。这里的TimingDecorator在概念上就是一个装饰器它在不修改Worker的前提下给run增加了计时能力。但因为组合发生在模板实例化时整个调用链最终会内联展开不会出现虚函数表查询和跨层间接调用。如果Base::run()本身不是虚函数编译器甚至能把TimingDecoratorWorker::run优化成一段完全直线型的代码。要注意这种变体并不是“经典意义的装饰器”。经典装饰器要求装饰后的对象还能以原接口的类型出现比如继续放进vectorunique_ptrDataSource里但TimingDecoratorWorker就是一个全新的类型它和Worker之间没有多态关系。因此它更适合静态调用链的场景比如 SDK 内部某个固定的算法流水线需要套日志和性能统计但对外并不需要暴露统一接口。它的另一个风险点是如果混用虚函数模板装饰器在继承层级里叠加会变得很绕。我一般建议把它当作“编译期增强器”来理解不要强行往 GoF 装饰器框架里硬套。2.3 函数式装饰器包装可调用对象与回调C 和 Java 的一个很大不同就是 C 不仅有对象还有一等公民的函数对象。装饰器模式完全可以直接作用在函数层面输入一个可调用对象输出另一个可调用对象。这就构成了第三种变体也是我在现代 C 项目里用得最多的一种因为它写起来最轻也不需要引入庞大的类继承体系。下面的代码给任意函数加计时能力#include chrono #include functional #include iostream #include type_traits #include utility templatetypename Fn auto withTiming(Fn fn) { return [fn std::forwardFn(fn)](auto... args) { auto start std::chrono::steady_clock::now(); if constexpr (std::is_void_v std::invoke_result_tFn, decltype(args)...) { fn(std::forwarddecltype(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::forwarddecltype(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::functionint(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 templatetypename Fn auto withRetry(Fn fn, int times) { return [fn std::forwardFn(fn), times](auto... args) { for (int attempt 0; attempt times; attempt) { try { return fn(std::forwarddecltype(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 templatetypename Fn auto withLogging(Fn fn, const char* name) { return [fn std::forwardFn(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_tFn, decltype(args)...) { fn(std::forwarddecltype(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::forwarddecltype(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_ptrPriceService next) : next_(std::move(next)) {} std::shared_ptrPriceService next_; }; class RetryingPriceDecorator final : public PriceServiceDecorator { public: RetryingPriceDecorator(std::shared_ptrPriceService 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_sharedLoggingPriceDecorator( std::make_sharedRetryingPriceDecorator( std::make_sharedHttpPriceService(), 3)); double price service-fetchPrice(AAPL);这里我特意用了shared_ptr而不是unique_ptr。原因是装饰器链中每一层都持有下一层如果后面想把这个服务同时传给两个客户端组件共享所有权会更方便。你当然可以用unique_ptr表达独占所有权那就调用方给什么、装饰器就接什么不要在里面偷偷再存一份裸指针。总的来说只要能明确所有权两种智能指针都行怕就怕写着写着又退回new和裸指针“图省事”。这个版本的另一个细节是日志装饰器里用try/catch捕获异常后记录再重新抛出。这保证了调用方拿到的异常语义和原始服务一致同时日志信息不会丢失。我见过有人为了图方便在装饰器里吞掉异常只返回默认值结果把调用方的错误处理逻辑全部打乱。装饰器可以加日志、加重试但不应该改变原始接口的失败语义除非业务上明确要求这样做。3.4 VSCode 下快速验证这些示例代码写出来总得跑一遍。如果你用的是 VSCode 搭 C/C 开发环境最简单的验证方式不是先配一堆复杂的构建脚本而是直接在终端里用编译器命令跑g -stdc17 -Wall -Wextra main.cpp -o demo ./demo命令行能跑通再考虑上 CMake。我一般会在项目根目录放一个最小的 CMakeLists.txtcmake_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 扩展用CtrlShiftP打开命令面板选择 “CMake: Select a Kit”把编译器指到本机的 GCC、Clang 或 Visual Studio Build Tools。这里有个我在实际配置中踩过多次的坑如果工程路径含有中文目录名某些 Windows 环境下的 CMake 和调试器会偶发找不到文件或断点不命中。不是百分百必现但一旦出现排查成本极高。我的建议是 C 工程一律放到纯英文路径下省下的时间远比改路径付出的时间多。至于代码补全和跳转如果发现 VSCode 里所有函数和变量都没法跳转通常不是代码本身的问题而是没有生成compile_commands.jsonC/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_uniqueCompressDecorator(fs); // fs 在函数结束后销毁但 deco 还活着这里CompressDecorator接收的参数类型应该是unique_ptrDataSource把fs这种裸地址硬塞进去本身就会触发编译错误除非你显式用了unique_ptrDataSource(fs)或者偷偷改了接口设计。一旦允许裸指针进入等到fs离开作用域而deco还在使用时访问虚表指针或成员变量就会踩到无效内存。第二条是缺少虚析构。基类DataSource如果没有virtual ~DataSource()通过基类指针删除派生对象时派生类析构逻辑不会执行。资源没有释放后续堆状态被破坏也许不会立刻崩但会在某个随机时刻表现为c0000005。这是典型的延迟崩溃特别难排查。所以继承式装饰器的基类析构函数务必写成virtual或者至少是protected非虚析构禁止通过基类指针删除。第三条是跨语言边界或回调场景下的生命周期错配。如果你要在 C# 里调用 C 的装饰器或者在异步回调里把std::function转成裸函数指针传给 C 接口必须额外注意std::function是一个 C 对象直接把它转成函数指针只会得到一个错误的地址。正确做法通常是维护一个全局表用一个整数句柄关联std::function回调函数通过句柄找回并调用。两端如果有一端把关联对象提前释放回调触发时就会崩出c0000005。我在实际项目里处理过好几回这种问题最后基本都是生命周期管理问题而不是调用约定问题。排查这类崩溃时工具很有用。Linux 下我优先上 AddressSanitizer只要编译时加-fsanitizeaddress -g悬空指针通常能直接定位到出错行Windows 下用 VS 自带的检测工具或者 WinDbg 抓调用栈也比闷头猜快得多。最重要的是看到c0000005不要急着怀疑编译器、怀疑平台先回头检查自己持有的对象是否还活着。4.2 性能开销到底有多大装饰器模式被诟病最多的一点是性能。我需要说一句公道话经典继承式装饰器的性能开销主要来自虚函数调用和嵌套层数但绝大多数业务系统里这点开销根本可以忽略。你一次网络请求消耗几毫秒装饰器多一次间接跳转消耗几纳秒完全不在一个量级。真正要警惕的是那些每毫秒执行几十万次的热点路径。在热路径上每增加一层运行时装饰器就多一次虚函数调用。一次虚函数调用通常意味着 CPU 要去查虚函数表再做一次间接跳转。现代 CPU 的分支预测对稳定的虚调用其实处理得不错但如果有多种派生类型交替出现分支预测就会失效。相比之下模板风格的编译期装饰器因为类型在编译期确定编译器可以做内联甚至可以把整个装饰链优化成一段线性指令。std::function的代价则取决于内部缓冲区能否容纳捕获对象现代实现通常有 small buffer optimization带入std::function的裸函数指针或无捕获 lambda 不需要堆分配但如果捕获一个大对象就会触发堆分配和拷贝。我把三种变体的取舍列成一张速查表方便你决策变体类型运行时开销组合灵活性类型透明性适用场景继承式运行时装饰器每层一次虚函数调用可能有一次堆分配高可在运行时动态组合高调用方只看基类接口插件系统、可配置流水线、跨接口调用模板/CRTP 编译期装饰器极低可内联零虚表开销低组合关系在编译期固定低装饰后是全新类型固定流水线、SDK 内部增强、高频调用函数式 lambda 装饰器取决于实现方式可能产生额外拷贝高装饰器也是可组合函数中返回新的可调用对象回调、异步任务、自由函数横切逻辑如果你在做性能敏感模块建议先用编译器输出看汇编。GCC 可以用-O2 -SClang 可以用-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_ptrPriceService buildOrderService() { return std::make_uniqueLoggingPriceDecorator( std::make_uniqueRetryingPriceDecorator( std::make_uniqueHttpPriceService(), 3)); }这样既能享受装饰器的灵活组合又不会让调用点被一串嵌套构造函数淹没。4.4 一点个人工作习惯如果让我给装饰器模式提炼一句使用心得我会说一开始先不要纠结“这是不是标准装饰器”先问自己三个问题。第一你的组合关系是运行时变化还是编译期固定第二调用方是否需要以统一接口处理装饰前后对象第三这个横切逻辑是否会经常增删这三个问题能帮你快速确定用继承式、模板式还是函数式变体。我还习惯为每个装饰器配一个极简的单元测试。比如只测“不加装饰时输出是什么加了日志装饰器后返回值不变只是多了输出”。装饰器的本质是透明增强透明性一旦被破坏组合成链后就会出现连锁反应。测试不复杂但能防止后面有人往装饰器里塞业务逻辑把它偷偷改造成奇怪的代理。如果你手头正好有一个老项目想给几个自由函数统一加重试或日志建议先尝试函数式装饰器因为它侵入性最小几乎不怎么改动现有代码结构。等验证了效果再决定要不要升级成继承式装饰器或模板化方案。这个顺序我在自己项目里反复用过失败成本很低效果来得最快。
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_ptrDataSource next) : next_(std::move(next)) {} std::unique_ptrDataSource 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_uniqueEncryptDecorator( std::make_uniqueCompressDecorator( std::make_uniqueFileDataSource(orders.dat)));这个变体的最大优点是透明。调用方只看到DataSource完全不知道里面套了几层以后加一层缓存装饰器也不用动调用方代码。维护上最需要注意的是两条铁律第一基类析构函数必须是virtual否则通过unique_ptrDataSource删除派生的EncryptDecorator时派生类析构函数不会被调用资源释放就可能出问题。第二组件对象的所有权一定要明确。用unique_ptr就是表示“装饰器独占这份资源”用shared_ptr就是表示“多个装饰器共享同一个底层对象”绝不能一个裸指针在不同层之间来回传。这种变体适合的场景是运行时组合、类型稳定、装饰器种类可以继续扩展。例如插件系统里用户在配置文件中写“启用压缩、启用加密”程序在启动时动态拼装对象。缺点是虚函数调用和对象分配会带来一点开销而且一旦嵌套层级深调用栈会变得难看调试时经常要在 IDE 里一层层往下点。2.2 模板与 CRTP 风格的编译期装饰器如果装饰器的组合关系在编译期就确定而且你希望把运行时开销压到零就可以使用模板风格的变体。这种写法本质上是一种混入mixin通过继承把行为贴到目标类上类型在编译期就完整展开。#include chrono #include iostream struct Worker { void run() { std::cout worker run\n; } }; templatetypename 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_caststd::chrono::microseconds( end - start).count() us\n; } };使用起来很直接TimingDecoratorWorker timedWorker; timedWorker.run();。这里的TimingDecorator在概念上就是一个装饰器它在不修改Worker的前提下给run增加了计时能力。但因为组合发生在模板实例化时整个调用链最终会内联展开不会出现虚函数表查询和跨层间接调用。如果Base::run()本身不是虚函数编译器甚至能把TimingDecoratorWorker::run优化成一段完全直线型的代码。要注意这种变体并不是“经典意义的装饰器”。经典装饰器要求装饰后的对象还能以原接口的类型出现比如继续放进vectorunique_ptrDataSource里但TimingDecoratorWorker就是一个全新的类型它和Worker之间没有多态关系。因此它更适合静态调用链的场景比如 SDK 内部某个固定的算法流水线需要套日志和性能统计但对外并不需要暴露统一接口。它的另一个风险点是如果混用虚函数模板装饰器在继承层级里叠加会变得很绕。我一般建议把它当作“编译期增强器”来理解不要强行往 GoF 装饰器框架里硬套。2.3 函数式装饰器包装可调用对象与回调C 和 Java 的一个很大不同就是 C 不仅有对象还有一等公民的函数对象。装饰器模式完全可以直接作用在函数层面输入一个可调用对象输出另一个可调用对象。这就构成了第三种变体也是我在现代 C 项目里用得最多的一种因为它写起来最轻也不需要引入庞大的类继承体系。下面的代码给任意函数加计时能力#include chrono #include functional #include iostream #include type_traits #include utility templatetypename Fn auto withTiming(Fn fn) { return [fn std::forwardFn(fn)](auto... args) { auto start std::chrono::steady_clock::now(); if constexpr (std::is_void_v std::invoke_result_tFn, decltype(args)...) { fn(std::forwarddecltype(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::forwarddecltype(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::functionint(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 templatetypename Fn auto withRetry(Fn fn, int times) { return [fn std::forwardFn(fn), times](auto... args) { for (int attempt 0; attempt times; attempt) { try { return fn(std::forwarddecltype(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 templatetypename Fn auto withLogging(Fn fn, const char* name) { return [fn std::forwardFn(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_tFn, decltype(args)...) { fn(std::forwarddecltype(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::forwarddecltype(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_ptrPriceService next) : next_(std::move(next)) {} std::shared_ptrPriceService next_; }; class RetryingPriceDecorator final : public PriceServiceDecorator { public: RetryingPriceDecorator(std::shared_ptrPriceService 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_sharedLoggingPriceDecorator( std::make_sharedRetryingPriceDecorator( std::make_sharedHttpPriceService(), 3)); double price service-fetchPrice(AAPL);这里我特意用了shared_ptr而不是unique_ptr。原因是装饰器链中每一层都持有下一层如果后面想把这个服务同时传给两个客户端组件共享所有权会更方便。你当然可以用unique_ptr表达独占所有权那就调用方给什么、装饰器就接什么不要在里面偷偷再存一份裸指针。总的来说只要能明确所有权两种智能指针都行怕就怕写着写着又退回new和裸指针“图省事”。这个版本的另一个细节是日志装饰器里用try/catch捕获异常后记录再重新抛出。这保证了调用方拿到的异常语义和原始服务一致同时日志信息不会丢失。我见过有人为了图方便在装饰器里吞掉异常只返回默认值结果把调用方的错误处理逻辑全部打乱。装饰器可以加日志、加重试但不应该改变原始接口的失败语义除非业务上明确要求这样做。3.4 VSCode 下快速验证这些示例代码写出来总得跑一遍。如果你用的是 VSCode 搭 C/C 开发环境最简单的验证方式不是先配一堆复杂的构建脚本而是直接在终端里用编译器命令跑g -stdc17 -Wall -Wextra main.cpp -o demo ./demo命令行能跑通再考虑上 CMake。我一般会在项目根目录放一个最小的 CMakeLists.txtcmake_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 扩展用CtrlShiftP打开命令面板选择 “CMake: Select a Kit”把编译器指到本机的 GCC、Clang 或 Visual Studio Build Tools。这里有个我在实际配置中踩过多次的坑如果工程路径含有中文目录名某些 Windows 环境下的 CMake 和调试器会偶发找不到文件或断点不命中。不是百分百必现但一旦出现排查成本极高。我的建议是 C 工程一律放到纯英文路径下省下的时间远比改路径付出的时间多。至于代码补全和跳转如果发现 VSCode 里所有函数和变量都没法跳转通常不是代码本身的问题而是没有生成compile_commands.jsonC/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_uniqueCompressDecorator(fs); // fs 在函数结束后销毁但 deco 还活着这里CompressDecorator接收的参数类型应该是unique_ptrDataSource把fs这种裸地址硬塞进去本身就会触发编译错误除非你显式用了unique_ptrDataSource(fs)或者偷偷改了接口设计。一旦允许裸指针进入等到fs离开作用域而deco还在使用时访问虚表指针或成员变量就会踩到无效内存。第二条是缺少虚析构。基类DataSource如果没有virtual ~DataSource()通过基类指针删除派生对象时派生类析构逻辑不会执行。资源没有释放后续堆状态被破坏也许不会立刻崩但会在某个随机时刻表现为c0000005。这是典型的延迟崩溃特别难排查。所以继承式装饰器的基类析构函数务必写成virtual或者至少是protected非虚析构禁止通过基类指针删除。第三条是跨语言边界或回调场景下的生命周期错配。如果你要在 C# 里调用 C 的装饰器或者在异步回调里把std::function转成裸函数指针传给 C 接口必须额外注意std::function是一个 C 对象直接把它转成函数指针只会得到一个错误的地址。正确做法通常是维护一个全局表用一个整数句柄关联std::function回调函数通过句柄找回并调用。两端如果有一端把关联对象提前释放回调触发时就会崩出c0000005。我在实际项目里处理过好几回这种问题最后基本都是生命周期管理问题而不是调用约定问题。排查这类崩溃时工具很有用。Linux 下我优先上 AddressSanitizer只要编译时加-fsanitizeaddress -g悬空指针通常能直接定位到出错行Windows 下用 VS 自带的检测工具或者 WinDbg 抓调用栈也比闷头猜快得多。最重要的是看到c0000005不要急着怀疑编译器、怀疑平台先回头检查自己持有的对象是否还活着。4.2 性能开销到底有多大装饰器模式被诟病最多的一点是性能。我需要说一句公道话经典继承式装饰器的性能开销主要来自虚函数调用和嵌套层数但绝大多数业务系统里这点开销根本可以忽略。你一次网络请求消耗几毫秒装饰器多一次间接跳转消耗几纳秒完全不在一个量级。真正要警惕的是那些每毫秒执行几十万次的热点路径。在热路径上每增加一层运行时装饰器就多一次虚函数调用。一次虚函数调用通常意味着 CPU 要去查虚函数表再做一次间接跳转。现代 CPU 的分支预测对稳定的虚调用其实处理得不错但如果有多种派生类型交替出现分支预测就会失效。相比之下模板风格的编译期装饰器因为类型在编译期确定编译器可以做内联甚至可以把整个装饰链优化成一段线性指令。std::function的代价则取决于内部缓冲区能否容纳捕获对象现代实现通常有 small buffer optimization带入std::function的裸函数指针或无捕获 lambda 不需要堆分配但如果捕获一个大对象就会触发堆分配和拷贝。我把三种变体的取舍列成一张速查表方便你决策变体类型运行时开销组合灵活性类型透明性适用场景继承式运行时装饰器每层一次虚函数调用可能有一次堆分配高可在运行时动态组合高调用方只看基类接口插件系统、可配置流水线、跨接口调用模板/CRTP 编译期装饰器极低可内联零虚表开销低组合关系在编译期固定低装饰后是全新类型固定流水线、SDK 内部增强、高频调用函数式 lambda 装饰器取决于实现方式可能产生额外拷贝高装饰器也是可组合函数中返回新的可调用对象回调、异步任务、自由函数横切逻辑如果你在做性能敏感模块建议先用编译器输出看汇编。GCC 可以用-O2 -SClang 可以用-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_ptrPriceService buildOrderService() { return std::make_uniqueLoggingPriceDecorator( std::make_uniqueRetryingPriceDecorator( std::make_uniqueHttpPriceService(), 3)); }这样既能享受装饰器的灵活组合又不会让调用点被一串嵌套构造函数淹没。4.4 一点个人工作习惯如果让我给装饰器模式提炼一句使用心得我会说一开始先不要纠结“这是不是标准装饰器”先问自己三个问题。第一你的组合关系是运行时变化还是编译期固定第二调用方是否需要以统一接口处理装饰前后对象第三这个横切逻辑是否会经常增删这三个问题能帮你快速确定用继承式、模板式还是函数式变体。我还习惯为每个装饰器配一个极简的单元测试。比如只测“不加装饰时输出是什么加了日志装饰器后返回值不变只是多了输出”。装饰器的本质是透明增强透明性一旦被破坏组合成链后就会出现连锁反应。测试不复杂但能防止后面有人往装饰器里塞业务逻辑把它偷偷改造成奇怪的代理。如果你手头正好有一个老项目想给几个自由函数统一加重试或日志建议先尝试函数式装饰器因为它侵入性最小几乎不怎么改动现有代码结构。等验证了效果再决定要不要升级成继承式装饰器或模板化方案。这个顺序我在自己项目里反复用过失败成本很低效果来得最快。
