策略模式大概是所有C开发者最早接触的那几个设计模式之一。我见过大量项目在三层继承之上堆了十几个策略类把多态玩得很花哨可一旦遇到组合策略、运行时装配、状态管理这些真实工程问题代码就开始失控。今天想聊的不是“面向接口编程”的入门概念而是把策略模式丢进实际项目里高级应用阶段必须面对的东西策略的生命周期、组合方式、配置驱动、编译期与运行期的取舍。这篇文章适合已经会用策略模式写简单示例、但希望在业务系统或底层模块中把策略用得更稳、更灵活的C开发者。1. 重新认识策略模式它解决的到底是什么问题1.1 一个最常见的业务场景假设在做一套订单计费系统订单支付前要算总价。同一个商品在不同活动下计价规则完全不同普通销售按单价大客户有阶梯折扣节假日用满减券跨境订单还要叠加汇率换算。最直观的写法就是if-else堆在计算函数里每个新规则加一个分支。这种写法前三个规则还吃得消到二十个规则时函数会膨胀到几百行修改任何一个分支都要担心其他分支被误伤。策略模式的出发点就是把“怎么做”从“什么时候做”里拆出来。计费函数只负责决定“当前该用哪个规则”规则本身封装成一个独立对象。这样新加一个规则就等于新加一个策略类原本的代码不动符合开闭原则。1.2 经典结构的本质不是接口而是“替换节点”教科书上的策略模式长这样抽象策略、具体策略、上下文。代码结构本身不难但很多人没意识到策略模式真正的价值是在流程里挖一个“可替换节点”这个节点让“算法选择”与“算法执行”解耦。class IPriceStrategy { public: virtual ~IPriceStrategy() default; virtual double calc(double rawPrice, const OrderContext ctx) const 0; }; class NormalPrice : public IPriceStrategy { public: double calc(double rawPrice, const OrderContext ctx) const override; }; class VipPrice : public IPriceStrategy { public: double calc(double rawPrice, const OrderContext ctx) const override; }; class OrderPricer { public: void setStrategy(std::unique_ptrIPriceStrategy strategy); double compute(const OrderContext ctx) const; private: std::unique_ptrIPriceStrategy m_strategy; };这里的接口抽象的是“一个行为”而不是“一个对象”。这就是策略和装饰器、责任链的边界所在装饰器包装并增强同一接口责任链传递请求直到有人处理策略则是在一组可替换的算法中选一个执行到底。1.3 什么时候该用什么时候该怀疑策略模式不是银弹。一个运算逻辑只有两个分支且几乎不会变硬拆策略类是过度设计但一个逻辑点被三类业务同时消费、每个业务又有多个路径时不用策略模式几乎必然会长出巨型函数。我建议用三个问题做判断这个逻辑会不会随业务迭代新增变体变体之间是否只是算法不同、而外部调用方式一致调用方是否需要在运行期切换算法三个都满足策略模式的收益就远大于维护成本。只有第一个问题满足且选型发生在编译期可以考虑后面要讲的模板策略方案。2. 高级应用的核心策略的生命周期管理2.1 先分清有状态与无状态策略很多人写策略时默认策略对象不保存数据函数执行完就扔。这在简单场景没错但高级应用里经常出现有状态策略一个压缩策略需要维护历史帧的统计信息一个风控策略要记录滑动窗口内的请求次数一个渲染策略要保存上一次输出的纹理句柄。无状态策略可以由多个上下文共享天然线程安全有状态策略必须明确生命周期的归属性。我的习惯是只要策略内部有非const的可变成员就视为有状态策略。有状态策略要么每次创建新实例要么用单独管理的方式保证互斥。2.2 策略实例的创建与销毁时机实际项目里的策略对象经常在请求进来时创建用完就释放。这在低频系统没问题但一个网关服务每秒处理上万请求时频繁new和delete策略对象会带来不小的allocator压力。更严重的是策略构造时可能加载配置、建立连接如果构造函数里有IO操作请求延迟会直接拉爆。我见过一个支付网关系统每次调用都重新构造一个验签策略策略构造函数里读取密钥文件。压测一开始就疯狂超时。后来改造成“无状态策略全局单例 有状态上下文分离数据”性能立刻回稳。这里的关键是让策略保持无状态把可变的数据放进请求上下文。比如验签策略本身不存“当前请求的签名”而是接收请求体、签名、密钥来源参数处理完就返回结果。这样同一个策略实例可以供所有请求复用。2.3 策略对象池与并发安全某些有状态策略确实必须跨请求保存状态。这时可以用对象池管理一组预先构造的策略实例每次从池里借一个用完归还。池需要处理并发简单做法是互斥锁保护空闲列表更高效的做法是用线程本地缓存把每个线程的池分开避免锁竞争。class StrategyPool { public: std::shared_ptrIStrategy acquire() { std::lock_guardstd::mutex lock(m_mutex); if (m_idle.empty()) { return std::shared_ptrIStrategy(m_factory(), [this](IStrategy* p) { release(p); }); } auto p std::move(m_idle.back()); m_idle.pop_back(); return std::shared_ptrIStrategy(p.release(), [this](IStrategy* q) { release(q); }); } void release(IStrategy* p) { std::lock_guardstd::mutex lock(m_mutex); m_idle.emplace_back(p); } private: std::mutex m_mutex; std::vectorstd::unique_ptrIStrategy m_idle; std::functionstd::unique_ptrIStrategy() m_factory; };这里用shared_ptr加自定义删除器是为了在引用计数归零时自动归还对象而不是真正删除。注意从池里拿出来的策略使用期间其他线程拿不到同一个个体所以状态互不干扰。如果策略本身要求逻辑上全局唯一而需要共享状态那又要另一套机制已经超出对象池的能力。2.4 策略依赖的外部资源策略对象常常依赖外部资源数据库连接、日志器、内存池、远端配置中心句柄。如果策略在构造时直接把资源拿在手里资源生命周期和策略生命周期强耦合很容易出现策略已销毁但资源还被别处引用的问题。我建议按资源所有权分三类处理资源外置策略通过参数接收资源不拥有、不释放资源归容器管理资源内置策略拥有unique_ptr资源策略销毁时资源随之释放资源共享策略持有shared_ptr且资源本身线程安全。大多数情况下策略应当“借用”外部资源而不是“拥有”外部资源。这样策略可以轻量创建和替换资源生命周期由更高层管理不容易悬挂。3. 策略的动态装配与组合真正体现高级价值的地方3.1 组合策略管线模式单一策略解决一个问题实际业务往往是多个策略叠加。比如文本审核流程先过滤敏感词再检查图片再判断是否命中用户举报黑名单。每一步是一个策略且顺序固定。如果用一个“管线策略”依次调下一环这就是组合模式加上策略模式。class PipelineStrategy : public ICheckStrategy { public: void addStep(std::unique_ptrICheckStrategy step) { m_steps.emplace_back(std::move(step)); } CheckResult check(const RequestContext ctx) const override { CheckResult last; for (auto step : m_steps) { last step-check(ctx); if (!last.pass()) return last; } return last; } private: std::vectorstd::unique_ptrICheckStrategy m_steps; };组合策略最需要注意的地方是步骤间的语义是“与”的关系且每一步的返回决定是否提前终止。这是短路语义。如果希望所有步骤都跑完再汇总则不能用提前终止要把结果收集起来统一判断。这两种语义会导致完全不同的行为命名时必须写清楚是AllPass还是FirstFail。另一个坑是步骤之间的数据传递。前面步骤可能会在ctx里写入中间结果后面步骤依赖这些结果。这要求ctx定义足够稳定否则前置策略一改字段名后面策略全部崩溃。3.2 责任链策略找到第一个“能处理的”管线策略和纯粹的责任链有一点微妙区别。责任链允许每一步判断“我能不能处理”不能则传给下一步能则处理并返回。管线策略则是每个步骤都强制执行只有pass/fail之分。实际项目里两种都会用到订单审核可能需要“命中黑名单直接拒绝”也可以“没有命中任何规则就放行”。如果希望“先匹配到哪个策略就用哪个策略处理”更合适的是把策略列表摆成一个责任链。class ChainStrategy : public IHandler { public: void append(std::unique_ptrIHandler h) { m_handlers.emplace_back(std::move(h)); } bool handle(RequestContext ctx) const override { for (auto h : m_handlers) { if (h-canHandle(ctx)) return h-handle(ctx); } return false; } private: std::vectorstd::unique_ptrIHandler m_handlers; };责任链的核心是canHandle和handle分开这一步的定位清晰。实际业务里链上某个handler无法处理当前上下文不代表整个流程失败而是继续找下一个。负责衔接的组合类要尽量不掺业务逻辑只做传递。3.3 配置驱动的策略装配策略模式到了高级阶段不可避免会和配置系统联动。一个复杂的业务系统可能有几十个策略如果每次新增策略都要修改工厂switch-case那配置系统的价值就没了。正确的做法是建立一个注册表策略类通过名字注册工厂按字符串查表创建实例。using StrategyCreator std::functionstd::unique_ptrIPriceStrategy(); class StrategyRegistry { public: static StrategyRegistry instance() { static StrategyRegistry reg; return reg; } void registerCreator(const std::string name, StrategyCreator creator) { m_creators[name] std::move(creator); } std::unique_ptrIPriceStrategy create(const std::string name) const { auto it m_creators.find(name); if (it m_creators.end()) { return nullptr; } return it-second(); } private: std::mapstd::string, StrategyCreator m_creators; }; #define REGISTER_STRATEGY_NAME(name, className) \ static bool _reg_##className [] { \ StrategyRegistry::instance().registerCreator(name, [] { \ return std::make_uniqueclassName(); \ }); \ return true; \ }();这一步做好之后新增策略只需要写一个新类加一行注册宏业务代码完全不用改。配置内容从数据库或配置文件读取策略名直接映射到创建函数。检查配置时先查registry查不到就返回nullptr调用方走fallback策略避免崩溃。需要特别小心的是注册宏展开时类名冲突。多个代码文件里注册宏的静态变量名都依赖类名可能重名。我在真实项目里加过注册顺序依赖的坑某个策略注册时依赖另一个策略已经注册结果静态初始化顺序不确定偶发崩溃。后来全部改成延迟创建用到才查表解决。3.4 策略与装饰器、代理模式的配合策略解决算法替换装饰器解决职责增强两者天然可以混用。一个图片压缩策略可以包一层“带日志的压缩策略”再包一层“带缓存的压缩策略”。外层策略不是替代算法而是给原策略加横切能力。实际项目中我希望“日志、监控、限流、缓存”这类横切关注点不要散落到各个策略里。包装成装饰策略之后业务策略保持单一职责所有横切逻辑集中到装饰类。注意装饰类必须实现原接口参数透传返回透传不能篡改业务语义。class LoggingCompressionStrategy : public ICompressionStrategy { public: LoggingCompressionStrategy(std::unique_ptrICompressionStrategy inner) : m_inner(std::move(inner)) {} CompressedData compress(const RawData raw) const override { auto start now(); auto result m_inner-compress(raw); log(compress elapsed, now() - start); return result; } private: std::unique_ptrICompressionStrategy m_inner; };包装链再深一点需要留意析构顺序和内存占用。如果装饰器层数过多调用栈变深性能热点会聚集在虚函数派发上。压缩这种CPU密集场景每多一层包装都可能在亿万次调用里放大开销。能合成装饰器的就合成不要纯为架构好看无限加层。4. C实现层面的几个实战手段4.1 std::function实现无继承策略传统虚函数策略有很多隐形成本每个策略对象有虚表指针、每次调用需要虚函数派发、类层次设计过重。但C还有另一种策略玩法不建抽象基类直接用std::function保存可调用对象。class OrderPricer { public: using CalcFn std::functiondouble(double, const OrderContext); void setCalcFn(CalcFn fn) { m_fn std::move(fn); } double compute(double raw, const OrderContext ctx) const { if (!m_fn) throw std::runtime_error(calc fn not set); return m_fn(raw, ctx); } private: CalcFn m_fn; };调用方可以直接传lambda、函数指针、函数对象不需要任何继承关系。这极大降低了策略的接入成本。对一个具体业务来说策略往往不是整个类而只是一个计算过程。std::function策略的场景代码最简洁。std::function也有代价底层会做类型擦除存储大对象时可能触发堆分配拷贝std::function有额外开销。我的建议是计算型策略优先用std::function状态型策略优先用类对象。4.2 编译期策略模板与CRTP如果可以确定策略在编译期固定那就没必要承担运行期多态开销。C最强大的一个地方是编译期策略把策略类型作为模板参数算法在编译期绑定。template typename Strategy class ImageProcessor { public: double process(const ImageData img) { return Strategy::process(img); } }; struct FastCompress { static double process(const ImageData img) { return compress_fast(img); } }; struct BestCompress { static double process(const ImageData img) { return compress_best(img); } };这样写的好处是零运行期开销策略逻辑直接内联到调用处。坏处是运行时无法切换不同策略实例化出不同的类模板类型之间没有统一接口不能随便放入容器。真正高级的组合是“编译期策略 运行期配置”模板参数固定了算法家族配置文件决定用哪个模版实例。很多底层库都这样做用户感知是同一个接口实际用的是不同模板参数实例。4.3 std::variant加访问器让策略“值”化C17之后std::variant可以安全保存一组类型中的一种。策略可以用variant替代继承体系把一个策略表达为一组可替换的“值”。配合访问器模式调用方用std::visit分发到具体类型。struct NormalStrategy { double calc(double raw) const { return raw; } }; struct VipStrategy { double rate; double calc(double raw) const { return raw * rate; } }; using PricerStrategy std::variantNormalStrategy, VipStrategy; class Pricer { public: double calc(double raw) const { return std::visit([](const auto s) { return s.calc(raw); }, m_s); } private: PricerStrategy m_s; };这里pricer不持有策略指针而是持有策略值。内存是连续栈存储没有虚表没有堆分配性能接近手写switch。缺点是新增策略要改variant声明不能完全开放扩展。适合策略集合封闭、运行期性能敏感的场景。4.4 类型擦除统一接口下的多实现类型擦除是“编译期定义能力运行期选择实现”的高级玩法。std::function本身就是类型擦除。如果希望不同类都有同一套成员函数但不强制继承也可以用类似方式实现自己的擦除器。class IStrategy { public: template typename Impl IStrategy(Impl impl) : m_self(std::make_sharedModelImpl(std::move(impl))) {} double run(const Ctx c) const { return m_self-run(c); } private: struct Concept { virtual ~Concept() default; virtual double run(const Ctx) const 0; }; template typename Impl struct Model : Concept { Model(Impl x) : m_impl(std::move(x)) {} double run(const Ctx c) const override { return m_impl.run(c); } Impl m_impl; }; std::shared_ptrconst Concept m_self; };外部看IStrategy就是一个普通值类型能拷贝、能存储、能按值传递实际内部通过虚函数调不同的实现。这个方案结合了值语义和运行期多态接口稳定扩展开放。代价是多一层shared_ptr间接以及内部虚调用。项目里如果没有现成的any-variant库手写类型擦除容易写出内存泄漏需要严格测试。我一般只在库接口的主题场景才用业务代码保持简单不主动造轮子。5. 工程案例某跨平台图像处理Demo的压缩策略模块5.1 需求背景与设计取舍某跨平台图像处理Demo需要统一处理PNG、JPEG、WebP、AVIF四种格式的压缩。输入源既有本地文件又有网络流输出场景包括缩略图、原图、无损压缩三种。不同平台性能差异很大同一个压缩算法在移动端和桌面端效果完全不同。按照标量式设计最好的办法是把“格式选择”和“压缩执行”分开成两层。格式选择层根据文件扩展名、magic number、配置文件的优先级决定用哪个解码器压缩执行层根据目标场景选择压缩策略。具体取舍上没有把所有逻辑做成一个大策略类。每个格式一个策略每个场景一个策略再通过组合和管线串起来。格式策略只负责“解码/编码这一种格式”压缩场景策略只负责“这一种场景的压缩参数”两个维度正交。5.2 关键代码骨架class ICodec { public: virtual ~ICodec() default; virtual bool decode(const std::vectoruint8_t input, ImagePixels out) 0; }; class PngCodec : public ICodec { public: bool decode(const std::vectoruint8_t input, ImagePixels out) override; }; class JpegCodec : public ICodec { public: bool decode(const std::vectoruint8_t input, ImagePixels out) override; }; class ICompressionStrategy { public: virtual ~ICompressionStrategy() default; virtual std::vectoruint8_t compress(const ImagePixels pixels) 0; }; class ThumbnailCompression : public ICompressionStrategy { public: std::vectoruint8_t compress(const ImagePixels pixels) override; }; class MultiFormatProcessor { public: explicit MultiFormatProcessor(std::unique_ptrICodec codec) : m_codec(std::move(codec)) {} void setCompressionStrategy(std::unique_ptrICompressionStrategy strategy) { m_compression std::move(strategy); } std::vectoruint8_t process(const std::vectoruint8_t input); private: std::unique_ptrICodec m_codec; std::unique_ptrICompressionStrategy m_compression; };组合时同一份ImagePixels从解码器产生由不同的压缩策略消费。代码里“格式策略”和“压缩策略”分开各自可扩展互不污染。这个结构下新增编码格式只需要加Codec新增压缩场景只需要加CompressionStrategy。两个维度的变化彼此独立这是组合策略设计的最佳收益。5.3 核心实现细节与踩坑大坑之一是策略对象在不同线程间的复用。Demo最初用同一个MultiFormatProcessor处理所有请求解码器内部有一个可变的临时buffer结果并发请求互相篡改buffer输出图像花屏。后来把buffer移出解码器放入ImagePixels上下文每个请求一个上下文策略保持无状态问题解决。另一个坑是压缩策略里对源图像的处理顺序不可调换。缩略图策略必须先缩放再压缩一旦先压缩再缩放带宽省了但CPU浪费低端设备卡顿明显。组合顺序必须通过策略的语义命名固定下来不能靠调用方自觉。内存控制也踩过坑。AVIF压缩的中间缓存非常吃内存多路并发时占用过GB。最后给策略加了一个“可预算策略”接口策略能在压缩前通知调用方自己需要多少临时内存调度器据此排队或降级到JPEG策略。5.4 演进过程中的经验这个Demo从最初“一种格式对应一个处理函数”演进到“解码器压缩策略配置驱动”一共经历了三次重构。第一次只是把if-else换成switch治标不治本第二次引入策略模式解决了新增格式时改旧文件的痛点第三次用注册表装配策略彻底把业务选择从编译期搬到了配置期。现在再看最值钱的不是那层多态接口而是“策略之间正交”的设计格式维度和压缩维度完全分离任何一个方向增加选项都不会牵动另一个方向。组合而非继承的策略组织方式让整套代码在新格式引入时几乎零改动。6. 常见问题与排查技巧实录6.1 策略接口膨胀导致每个策略都实现一堆无关方法接口抽象得太大会逼着每个策略实现一堆和自己无关的方法。压缩策略被要求实现traceId回调、日志上报、流控接口一个类塞满噪音。对策是拆分接口。用“窄接口”代替“胖接口”每个策略只定义自己的核心行为调用方用if constexpr或dynamic_cast识别能力。现代C更推荐在接口里提供默认实现策略只覆写自己关心的部分。另一个实用技巧是接口提供带默认参数的辅助模板方法让调用方不关心直接域。6.2 策略对象共享导致状态污染无状态策略被误加了内部缓存、计数器或临时变量多个线程共享时结果错乱。排查时可以从“能稳定复现”和“偶发乱值”判断稳定复现多半是初始化缺失偶发乱值多半是并发写入。对策是把可变数据全部移到上下文对象策略只读不写。若确有真实状态用thread_local或者将策略放入对象池按请求分配。6.3 虚函数策略和模板策略选型混乱同一个项目里运行时策略大量使用虚函数编译期策略大量使用模板两边风格混用维护起来非常痛苦。我的个人选型标准场景推荐方案理由运行时选择算法复杂、有状态虚函数策略灵活可替换天然支持组合运行时选择算法简单、无状态std::function成本低接入快无虚表指针冗余编译期固定性能关键模板/CRTP零开销内联类型安全策略集合封闭性能敏感variantvisit栈存储无堆分配无虚表接近手写需要跨库传递值语义策略类型擦除接口稳定值语义但层次复杂没有处处工程标准的团队至少在设计文档里把使用规则定下来避免一半类走模板一半类走虚函数。6.4 配置加载失败时策略缺失策略名写错、版本升级后旧配置残留、配置中心下发延迟都可能导致工厂创建策略返回nullptr。最坏情况是业务判空漏掉直接解引用空指针崩溃。对策是提供哨兵策略NullStrategy工厂查表失败时返回哨兵对象业务调用不崩且有明确错误日志。哨兵策略最好实现Strategy接口行为是“记录错误并返回合理默认值”而不是吞掉异常继续正常流程。6.5 策略切换期间的并发竞态需要动态切换全局策略时如配置热更新切换和调用同时发生会导致一部分请求用旧策略、一部分用新策略。如果新旧策略不兼容可能产生脏数据。稳妥做法是“不可变策略 发布式替换”。每个策略实例一旦创建不修改其行为替换时用一个原子指针指向新实例调用方在进入时只读一次指针之后整个调用期间保持一致。class Pricer { public: void setStrategy(std::shared_ptrIPriceStrategy s) { std::atomic_store(m_strategy, std::move(s)); } double calc(const Ctx ctx) { auto s std::atomic_load(m_strategy); if (!s) return ctx.basePrice(); return s-calc(ctx); } private: std::shared_ptrIPriceStrategy m_strategy; };用shared_ptr做原子替换时注意旧策略可能还有请求在跑但不会马上释放等所有引用归零才析构安全。这是一个非常实用的发布模式。6.6 组合顺序引发的语义错乱管线策略里A策略在B策略前执行和B在A前执行结果可能完全不同。业务方常常分不清“先校验格式再压缩”和“先压缩再校验格式”的区别。设计组合策略时必须在接口文档或类名里明确顺序语义。我习惯在PipelineStrategy内部维护一个stepName列表日志里打印每一步的执行顺序。这样线上问题能快速定位到是配置顺序错乱还是策略本身错误。现象可能原因排查手段新策略不生效注册名与配置文件不一致查注册表和配置键结果偶发错误策略内部有状态且被共享把状态移到上下文或对象池性能突然劣化策略组合层数过多用profile看函数热点合并装饰层切换策略后旧请求崩溃旧策略被提前释放用shared_ptr原子发布方案相同输入不同输出缓存或配置更新的时序问题检查发布逻辑与缓存键策略A依赖B的数据但B未执行Pipeline顺序配置错误在日志中打印实际执行顺序最后再分享一个实操细节策略模式在代码评审里最容易被挑的问题就是“策略类和策略文件夹爆炸”。缓解办法是按语义域分包而不是把所有策略丢进一个strategy目录。订单策略放order/strategy图像策略放image/codec不要让一个目录变成几百个文件的垃圾场。我在实际项目里维护过来的习惯是策略类的名字必须以领域行为开头比如DiscountStrategy比AbstractPriceStrategyRuleServiceImpl这种命名可读性好得多。一个好的策略命名让新人看到类名就知道这个策略在外部流程的哪个节点生效。