1. 策略模式到底在解决什么问题先看一段代码。我接手过一个商城项目第一版订单结算长这样根据用户类型算折扣金牌、银牌、普通用户各一套规则后面又加了节日促销、新人首单、会员日翻倍。半年之后calculate方法变成了这样public BigDecimal calculate(Order order) { if (GOLD.equals(order.getUserLevel())) { // 金牌会员 8 折满 100 减 20叠加积分抵扣... } else if (SILVER.equals(order.getUserLevel())) { // 银牌会员 9 折满 50 减 5... } else if (NORMAL.equals(order.getUserLevel())) { // 普通用户无折扣包邮门槛 99... } else if (NEW_USER.equals(order.getUserLevel())) { // 新用户立减 15首单再打 95 折... } // 后面还有 6 个分支 }每次加新规则都要在方法体里再塞一个else if改完还要担心影响其他分支。更难受的是测试为了测金牌会员的折扣得先把前面六个条件全部走到测试用例越长越不敢动。这就是策略模式要解决的痛点。它的核心思想很朴素把一系列可替换的算法封装起来让使用者通过统一入口选择而不是把一个方法堆成巨型 if-else。如果你是从“Java 设计模式”这个概念开始看起的那策略模式大概率是你第一个真正能用得上的模式。这套东西适用面太广了登录鉴权用微信、支付宝、手机号分别处理短信发送用阿里云、腾讯云、自研通道支付场景里微信支付、支付宝、云闪付解析文件时对不同格式各写一套解析器。这些场景的共同特征是业务逻辑随参数的不同走完全不同的分支而分支之间互不想通但对外要暴露一致的入口。策略模式的价值就是把这层”入口“稳住把”分支“各自拆出去让新增算法就像插 U 盘一样。这篇文章适合三类人准备把策略模式写进项目里又怕写歪的初级 Java 工程师正在写设计模式大作业、需要交一份能讲清楚原理还能跑通 Demo 的学生以及备战 Java 面试、需要把八股问出深度的候选人。我会从最小代码起步一路讲到 Spring Boot 项目的落地写法、面试官高频追问、以及我踩过的真实坑位。2. 策略模式的三要素与最小可运行代码2.1 三要素是什么策略模式有三个角色先记牢这三个名字后面所有的代码都是围绕它们转的。Strategy抽象策略定义算法的统一接口通常是接口或者抽象类里面声明一个核心方法。ConcreteStrategy具体策略实现抽象策略每个具体策略封装一套完整算法。Context上下文持有抽象策略的引用负责把客户端和具体策略隔开客户端只需要跟 Context 打交道。生活化类比你在外卖平台点餐”配送方式“就是抽象策略它定义了”把餐送到你手上“这个动作。骑手配送、到店自取、无人车配送是三个具体策略。而平台的订单页就是 Context它会根据你选的配送方式执行对应那套送达流程。你作为用户不需要关心无人车怎么调度、骑手怎么接单你只需要在页面上点一下。2.2 最小可运行代码用电商折扣场景写一个最小 Demo。先定义抽象策略public interface DiscountStrategy { // 传入折扣前金额和订单信息返回折扣后金额 BigDecimal apply(Order order, BigDecimal amount); }然后写三个具体策略public class NormalDiscount implements DiscountStrategy { Override public BigDecimal apply(Order order, BigDecimal amount) { // 普通用户不打折但满 99 包邮 return amount; } } public class GoldDiscount implements DiscountStrategy { Override public BigDecimal apply(Order order, BigDecimal amount) { // 金牌会员 8 折 return amount.multiply(new BigDecimal(0.8)); } } public class NewUserDiscount implements DiscountStrategy { Override public BigDecimal apply(Order order, BigDecimal amount) { // 新用户立减 15再打 95 折 return amount.subtract(new BigDecimal(15)) .multiply(new BigDecimal(0.95)); } }最后是 Contextpublic class OrderContext { private DiscountStrategy strategy; public OrderContext(DiscountStrategy strategy) { this.strategy strategy; } public void setStrategy(DiscountStrategy strategy) { this.strategy strategy; } public BigDecimal calculate(Order order, BigDecimal amount) { return strategy.apply(order, amount); } }调用方这样用Order order new Order(); order.setUserLevel(GOLD); BigDecimal amount new BigDecimal(100); OrderContext context new OrderContext(new GoldDiscount()); BigDecimal result context.calculate(order, amount); // 输出 80.0这段代码看着简单但里面有三个细节值得展开。第一Context 不是必须的吗有人会问我直接new GoldDiscount().apply(order, amount)不也能算出来确实能算但调用方把策略的选择权和使用权耦合在一起了。一旦订单类型有几十种调用方就要亲自写分支去选择策略那 if-else 只是从 Context 里搬到了调用方问题没解决。Context 存在的意义是隔离变化调用方只管拿结果策略的选择和维护都交给 Context 统一管理。第二构造器传策略和 setter 传策略有什么区别如果业务场景里一个订单的折扣算法中途不会改变优先用构造器注入保证策略不可变避免运行中误改导致金额算错。如果策略可能在同一个对象生命周期内动态变化比如先走优惠、再走换购那就用 setter 或者一个changeStrategy()方法。绝大多数业务用构造器就够了动态切换的场景远比你想象中少。我见过有人为了灵活性强行上 setter结果排查问题时还得猜当前是哪个策略没必要。第三apply 方法里要不要传 Order策略接口的方法签名直接决定策略能读到哪些上下文信息。如果你只传一个金额那按用户等级算折扣的策略就永远实现不了因为 Order 里的用户等级字段读不到。反过来如果方法签名传整个 Order那所有策略都能访问订单全量信息但这也意味着策略和订单模型强绑定了。这个问题没有标准答案关键看你的策略未来会用到哪些数据尽量在接口设计时留够余地避免后面为了加一个省份字段把接口签名改得面目全非。我给一个经验接口参数优先传最小必要信息集合。如果没有复杂上下文依赖传基础数据类型即可如果有就把 Order 这种大对象传进去。后者虽然不优雅但 Java 项目里大部分人是这么干的实测最省事。2.3 运行逻辑和 Java 动态绑定策略模式能自动找到正确算法靠的是 Java 的多态和动态绑定机制。当你持有父类型引用DiscountStrategy strategy new GoldDiscount()时调用strategy.apply()会实际执行GoldDiscount的方法而不是接口声明里的方法。虚拟机在运行时根据实际对象类型决定方法入口这就是所谓动态绑定。很多 Java 初学者对这块理解不够导致写策略模式时总想在 Context 里写 switch 判断实际类型那就绕回去了。记住一句话策略模式里策略选择发生在创建具体策略对象那一刻而不是调用方法那一刻。判断逻辑写在创建策略的地方工厂或客户端方法调用不需要任何判断。3. 真实项目里的落地Spring Boot 工厂 Map 来管理策略上一章的最小代码只适合教学和应付大作业真正往 Spring Boot 项目里放得再进化一层。为什么因为最小代码里策略对象的创建和使用还是要靠调用方手写new。如果订单类型有 12 种结算业务里就要写 12 次new XxxStrategy()这还是等于把分支逻辑散落在业务代码里。我的做法是策略实现类交给 Spring 管理用一个工厂类通过 Map 访问策略调用方只跟工厂打交道。这也是我见到的主流 Spring 项目里最常用、最稳妥的写法。3.1 代码结构public interface PayStrategy { String payType(); // 策略标识如 WECHAT、ALIPAY、CARD void pay(Order order); }Component(wechatPayStrategy) public class WechatPayStrategy implements PayStrategy { Override public String payType() { return WECHAT; } Override public void pay(Order order) { // 微信支付 SDK 调用逻辑 } }Component(alipayStrategy) public class AlipayStrategy implements PayStrategy { Override public String payType() { return ALIPAY; } Override public void pay(Order order) { // 支付宝 SDK 调用逻辑 } }Component public class PayStrategyFactory { // Spring 会把所有 PayStrategy 实现类注入这个 Map // key 是 bean 名称 private final MapString, PayStrategy strategyMap; public PayStrategyFactory(MapString, PayStrategy strategyMap) { this.strategyMap strategyMap; } public PayStrategy getStrategy(String payType) { PayStrategy strategy strategyMap.get(payType); if (strategy null) { throw new IllegalArgumentException(Unsupported pay type: payType); } return strategy; } }调用方RestController public class PayController { Autowired private PayStrategyFactory factory; PostMapping(/pay) public Result pay(RequestBody PayRequest request) { String payType request.getPayType(); PayStrategy strategy factory.getStrategy(payType); strategy.pay(request.toOrder()); return Result.success(); } }这段代码有两个关键机制值得单独讲。Map 自动注入的逻辑。MapString, PayStrategy是 Spring 提供的特殊注入方式当一个接口有多个实现类时Spring 会自动把这组 bean 放进一个 Mapkey 默认是 bean 名称。所有Component标注的策略类都会在容器启动时被收集。这就是为什么getStrategy(WECHAT)能直接拿到微信支付策略。这个机制省掉了手写 if-else 注册表而且新增策略类时连工厂都不用动完美契合开闭原则。bean 名称和 payType() 的对应关系。我用Component(wechatPayStrategy)这种显式命名来保证 bean 名称稳定可控避免类名修改后 Map key 跟着变。而payType()方法返回的WECHAT是给业务层看的标识跟 bean 名称不一定一致。工厂默认用 bean 名称作为 key所以调用方传的 payType 要能对上 bean 名称。如果你希望 key 用payType()方法的返回值那工厂里需要改成遍历拿到每个策略再取payType()存一遍虽然多一步但对调用方更友好。我见过很多项目里把这两者的对应关系写得很隐晦导致加策略时 key 对不上排查半小时。我的建议是要么统一用 bean 名称要么统一用 payType() 返回值二选一并在工厂类里写明注释。3.2 为什么要用工厂包一层有人觉得直接在业务代码里MapString, PayStrategy注入然后map.get(type).pay(order)不就行了确实可行。但我仍然建议加工厂类原因有三个。第一工厂可以集中处理策略为空的异常。业务代码里直接map.get()拿到 null 之后你怎么处理很多人会写if (strategy null) { return Result.error(不支持的支付方式); }这个判断散落在各个调用方逻辑不统一。收进工厂一次写完到处生效。第二工厂可以包装策略初始化逻辑。有些策略需要在创建时加载配置、初始化连接池。如果业务代码直接拿 bean这些初始化逻辑没法统一管理。工厂里可以加afterPropertiesSet()或者构造器逻辑来处理。第三工厂接口给调用方一个稳定的入口。将来如果要把策略改成从数据库动态配置或者加入策略黑名单、灰度切换这些扩展逻辑都可以塞进工厂调用方完全感知不到。这不正是策略模式想要的隔离变化吗工厂就是隔离变化的那层皮。3.3 配合 Spring 的坑位提醒用 Spring 管理策略类有个隐形问题如果两个策略类上的Component名称一样或者某个类同时实现了多个策略接口Map 注入时会出现重复或类型不匹配问题。我踩过最典型的坑是策略接口有默认方法某个实现类漏了 override结果调用时静默执行了默认逻辑库存扣了但积分没加。排查了两个小时才通过日志发现走的根本不是预期策略。这里给三条实用建议策略实现类务必显式标注Component(具体的名字)不要依赖类名首字母小写这种默认规则太脆弱了。策略接口的方法一定要有清晰的注释说明每个参数的来源防止实现类之间对参数含义理解不一致。上线前写一个启动检查器枚举出所有策略的payType()看看有没有重复标识。这步做成单元测试最顺手下面会讲。4. 策略模式的高频变体枚举加 Lambda、模板方法结合、责任链搭配策略模式的经典写法是所有设计模式教程都会教的但真实工程里你大概率会见到另外三种变形。它们不是对策略模式的背叛而是针对不同场景做的裁剪。4.1 变体一枚举加函数式接口的轻量策略如果一个策略的核心逻辑只有一行或几行不要为它单独建类。Java 8 以后我推荐用枚举实现轻量策略。public enum OrderTypeEnum { NORMAL(1, (order, amount) - amount), GOLD(2, (order, amount) - amount.multiply(new BigDecimal(0.8))), NEW_USER(3, (order, amount) - amount.subtract(new BigDecimal(15)) .multiply(new BigDecimal(0.95))); private final int code; private final BiFunctionOrder, BigDecimal, BigDecimal calculator; OrderTypeEnum(int code, BiFunctionOrder, BigDecimal, BigDecimal calculator) { this.code code; this.calculator calculator; } public BigDecimal calculate(Order order, BigDecimal amount) { return calculator.apply(order, amount); } public static OrderTypeEnum fromCode(int code) { return Arrays.stream(values()) .filter(e - e.code code) .findFirst() .orElseThrow(() - new IllegalArgumentException(unknown type: code)); } }这个写法的好处是策略的定义和策略标识放一起查代码时一眼就看全不需要 Spring 加持单元测试好写Lambda 表达式把样板代码压到最低。缺点也很明显如果某个策略逻辑超过十几行塞在 Lambda 里阅读体验极差而且枚举不支持从外部扩展新增策略必须改枚举本身这就违反开闭原则了。所以我总结的取舍标准是策略数量不超过 6 个并且单个策略逻辑不超过 10 行用枚举加 Lambda 很香策略数量多、逻辑复杂、还想支持扩展时老老实实用上文的 Spring Map 方案。4.2 变体二策略模式和模板方法的组合很多策略之间共享相同的骨架只有某一步不同。比如所有支付策略都要经历格式校验 → 调起支付 → 记录流水 → 发送通知只有中间调起支付这一段不同。这时候把公共流程抽到抽象父类里用模板方法定义骨架子类只实现差异部分比每个策略各写一遍完整流程要稳得多。public abstract class AbstractPayStrategy implements PayStrategy { Override public void pay(Order order) { validate(order); // 公共校验订单 doPay(order); // 抽象子类实现 saveFlow(order); // 公共记录支付流水 notifyUser(order); // 公共发通知 } protected abstract void doPay(Order order); protected void validate(Order order) { // 默认校验逻辑 } protected void saveFlow(Order order) { // 公共流水记录逻辑 } protected void notifyUser(Order order) { // 公共通知逻辑 } }这样写公共逻辑只维护一份新策略只需要继承抽象类、实现doPay()。注意这个抽象类并不影响原先的 Map 注入Spring 依然会把每个子类当作 PayStrategy 的实现注入工厂。这种组合我设计订单处理、消息推送、文件解析时用过多次效果都非常好。4.3 变体三策略和责任链的搭配有些场景下一套算法不是一个策略能完成的而是一串策略按顺序执行。比如下单流程要走库存校验 → 优惠计算 → 积分累计 → 清空购物车每一步都可能被多种算法替换那光用策略模式就没法表达顺序编排。我的做法是每个策略实现类里持有一个next引用或者用 Spring 的ListStepHandler注入按序执行。用 List 注入是更优雅的写法public interface OrderStepHandler { void handle(OrderContext context); int order(); }Spring 按order()排序后全部 handler 依次执行。每个 handler 就是一个独立的策略单元组合起来就是一条责任链。这样既保留了策略的可替换性又用链式编排表达了流程顺序。面试的时候能说出这个变体并且解释清楚两种模式的边界在哪里会比单纯背八股高一个层次。5. 面试官最常追问的 6 个策略模式问题5.1 策略模式和状态模式有什么区别这是面试最高频问题。策略模式的核心是算法的替换调用方主动选择使用哪个策略策略之间是平行的、互不依赖。状态模式的核心是状态驱动的行为切换对象内部状态发生变化时自动切换行为调用方通常不感知状态变迁。举个例子购物车结算选微信支付是策略因为这是用户开始支付时做的选择订单状态从待发货变成已发货后消息推送方式自动变化这是状态。识别要点就一句话选择是外部指令还是内部状态驱动的。5.2 策略模式和简单工厂模式是什么关系简单工厂是一个创建对象的地方根据参数返回不同类型的对象策略模式关心的是这些对象如何被使用。两者经常搭配出现但角色不同。我项目里的PayStrategyFactory实际上就是简单工厂它负责根据 payType 创建策略对象而业务代码是策略模式的客户端它持有接口引用并调用统一方法。面试时能主动说出工厂管创建、策略管行为两者互补这个点会比较加分。5.3 策略模式为什么说满足开闭原则但也不是万能解新增一个策略实现类不需要修改已有策略类Spring 模式下连工厂都不用改符合开闭原则。但注意如果你用的是枚举加 Lambda 写法新增策略必须改枚举本身这时候就不满足开闭原则了。这不是说枚举写法不好是提醒你任何设计都是有代价的。策略模式的核心代价是类数量膨胀12 种规则就是 12 个类如果小项目只有 2 个规则硬上策略模式反而增加维护成本。请记住一句经验if-else 有了第三个分支时再考虑上策略模式两个分支以内直接写 if-else 最简洁。5.4 Spring 环境下使用策略模式有哪些注意点高频答案集中在三点第一策略类要交给 Spring 管理避免手动 new 导致内部依赖注入失效第二注意 Map 注入的 key 和业务标识的对应关系建议统一命名并在测试里做兜底校验第三如果策略之间有共享逻辑用抽象父类或模板方法收敛别在多个子类里复制粘贴。回答这三点同时展示出你踩过坑的细节面试官通常不会再往下追问。5.5 策略接口的参数设计为什么重要参数设计是策略模式最容易翻车的环节。接口参数太少后续扩展时发现信息不够被迫改签名参数太复杂每个策略都被迫依赖无关数据。比较好的做法是先明确策略执行时需要哪些上下文信息再用一个上下文对象或泛型约束来传参。比如支付策略需要订单号、金额、回调地址就封装一个PayContext而不是直接传完整订单实体折扣策略需要金额和用户等级那接口签名就传这两个参数。好的接口参数设计能支撑业务演进至少三年坏的参数设计会让你半年后就得大改。5.6 策略模式在实际项目中最常结合的设计模式有哪些这个问题考的是工程视野。最常结合的三个工厂模式管策略对象的创建模板方法管策略内部的公共骨架责任链管策略编排。把它们之间的关系讲清楚是面试官判断你是否真正写过设计模式而不是背背书的最快方式。6. 常见坑位与实战排查记录6.1 坑位一Map 注入 key 理解错位有一次接手的项目里策略类用Component(LOGIN_PWD)定义 bean 名称业务参数传的是pwd_login结果getStrategy(LOGIN_PWD)查不到。排查时发现调用方写的是枚举里的 code而工厂用 bean 名称做 key。规范的解决办法是工厂构造器里遍历所有策略用payType()返回值作为 key 重新组装一张 Map这样业务侧标识永远对应payType()不依赖 bean 名称。Component public class PayStrategyFactory { private final MapString, PayStrategy strategyMap; public PayStrategyFactory(ListPayStrategy strategies) { this.strategyMap strategies.stream() .collect(Collectors.toMap(PayStrategy::payType, Function.identity())); } public PayStrategy getStrategy(String payType) { PayStrategy strategy strategyMap.get(payType); if (strategy null) { throw new IllegalArgumentException(unsupported: payType); } return strategy; } }6.2 坑位二策略类里注入 Service 失效如果你在策略实现类里Autowired了一个 Service但调用方不是从 Spring 容器拿的策略对象而是自己new出来的那这个注入必然失效。最典型的是在工具类里new WechatPayStrategy()后在策略里调userService直接空指针。一个经验是策略类永远从 Spring 容器获取业务代码不手动 new 策略类。写单元测试时宁可构造完整 IoC 容器或者手动 mock也不要图省事手动 new 导致线上翻车。6.3 坑位三策略标识重复悄悄覆盖Collectors.toMap()遇到重复 key 默认抛异常算是帮我们拦了一道。但如果用的是 Map 手动 put 的老写法重复 key 会静默覆盖上线后部分用户走了错误策略还不容易发现。建议在工厂初始化时使用toMap(key, value, (oldValue, newValue) - newValue)并打警告日志或者直接让异常抛出来——重复标识本身就是设计错误就该在启动期暴露。6.4 坑位四策略模式滥用导致类爆炸有个同事把一个只有两个分支的判断用策略模式重写结果类从 2 个变成 6 个代码量翻倍可读性反而下降。这就踩了过度设计的典型坑。我的判断标准分支数量到 3 个以上才开始重构并且每次新增策略时看成本。如果加一个策略类只需要新建一个类、写十几行逻辑那这个模式是健康的如果加一个策略要改工厂、改配置、改数据库表那模式重了该砍。6.5 单元测试怎么写才有效策略模式的单元测试核心是验证两个问题策略选择是否正确、策略算法是否正确。策略算法测试很容易针对每个策略类写独立测试覆盖边界值。策略选择测试放在工厂层写Test void should_get_correct_strategy_by_pay_type() { String payType WECHAT; PayStrategy strategy factory.getStrategy(payType); assertTrue(strategy instanceof WechatPayStrategy); } Test void should_throw_when_pay_type_unsupported() { assertThrows(IllegalArgumentException.class, () - factory.getStrategy(UNKNOWN)); }我习惯再写一条全局扫描测试遍历所有策略实现类断言payType()返回值不重复、不为空。这一条测试放 CI 里能在开发阶段就拦住很多配置错误。6.6 日志与排查建议策略模式在运行时的排查难点在于看到日志只显示调用 PayStrategy这个抽象层很难直接定位到具体策略。我的建议是工厂的getStrategy()方法里记录一行日志包含入参 payType 和返回的策略类名策略执行方法里再记一行业务日志。两层日志对应起来排查效率能翻一倍。别怕多打日志策略模式这种情况就属于日志越详细运维越轻松的典型案例。7. 我的个人使用经验与改进建议我前前后后在各种项目里用过不下十次策略模式从最开始照模板一顿抄到后面慢慢摸索出一些自己的习惯最后分享几个实用的改进方向。第一策略接口尽量往上抽象一层。比如支付策略不要只定义pay(Order order)可以再拆一个getPayParams(Order order)和afterPay(Order order)这样策略和支付结果的解耦程度会明显更高。第二策略工厂没有必要打开接口给别人重写我一般会在工厂里加一个strategyCount()方法启动后输出当前注册的策略总数一眼看出有没有缺失。第三策略模式内部养成分层习惯Controller 层只负责拿到 payType 字符串Service 层组装业务参数Strategy 层只做纯逻辑不出参、不落库、不发消息。把策略类保持纯净你会发现自己做单元测试的意愿高了很多。如果你在学习过程中把策略模式和其他模式混在一起也不必焦虑。设计模式本来就不是孤立的教条它是实践经验的总结。先把最简单的 if-else 替换跑通再逐步加入工厂、模板、责任链最后你会形成自己的一套写法。理解了模式背后的思想比记住任何代码模板都更重要——模式是活的项目是活的你的设计能力也会随之活起来。