企业官网建设流程全解析

1. 项目概述：为什么订单折扣逻辑必须用策略模式重写

最近在帮某电商平台做促销模块重构时，团队里一位刚转正的后端同学交上来一个“万能折扣计算类”——里面塞了二十多个 if-else 分支，从“新用户首单立减5元”到“满399减88叠加跨店满减”再到“黑卡会员专属阶梯返现”，全靠 switch(code) 硬编码。上线第三天，运营临时加了个“早鸟预售定金膨胀200%”规则，他改完代码发版，结果把所有非预售订单的折扣都算成了0。回滚后，技术负责人直接在晨会上说：“这不是写代码，是在给系统埋雷。”

这就是我决定启动【设计模式实践系列】的起点。标题里这个“策略模式应用订单折扣方案”，不是教科书里的玩具示例，而是我们真实压测过、灰度跑过、支撑日均80万笔订单的生产级实现。它解决的核心问题非常具体：当折扣规则从3种增长到37种，且每种规则的计算逻辑、生效条件、优先级、数据依赖各不相同，如何让新增一种规则不碰老代码、不改公共方法、不重启服务、不引发回归风险？答案不是加注释、不是写文档、更不是靠人肉review，而是用策略模式把“折扣算法”变成可插拔的零件。

你可能会问：不就是if-else换成Map<Code, Strategy>吗？真没那么简单。我在实际落地中发现，90%的团队卡在三个隐形门槛上：第一，策略的上下文怎么传——是只传订单金额，还是得带用户等级、商品类目、下单时间、地域标签、设备指纹？第二，策略之间怎么协作——比如“满减”和“优惠券”谁先扣、谁后扣、能不能叠加？第三，策略怎么热更新——运营半夜改个阈值，难道要等凌晨三点发版？这些细节，恰恰是策略模式能否从Demo走向生产的关键分水岭。接下来我会把这整套方案拆开揉碎，从类图设计到Spring Boot自动装配，从策略优先级调度到Redis缓存预热，全部用真实参数、真实日志、真实压测数据说话。无论你是刚学完《Head First》的设计模式新手，还是被线上bug追着跑的资深开发，这篇都能让你明天就改掉自己项目里那个臃肿的DiscountService。

2. 整体架构设计与选型逻辑：为什么不用状态模式、也不用责任链

2.1 为什么是策略模式，而不是其他模式？

看到“订单折扣”四个字，很多同学第一反应是责任链（Chain of Responsibility）——让每个折扣规则像链条一样依次执行，满足条件就扣减。但我们在压测中很快否定了这条路。原因很现实：责任链天然要求顺序强依赖，而业务规则根本不存在绝对先后。举个例子：“满299减30”的满减规则，和“指定品类打8折”的品类折扣，哪个该先算？如果先算满减，用户买两件99元商品（总价198），不触发满减，但若先算8折，总价变成158.4，依然不触发；可如果用户再加一件102元商品，总价300，此时先算满减得270，再8折得216；但若先8折再满减，300×0.8=240，再减30得210——结果差6元。财务对账时，这6元就是事故。

我们拉出近三个月的客诉工单分析，发现73%的“折扣计算不一致”投诉，根源都在这种隐式执行顺序。而策略模式的核心价值，恰恰在于解耦“选择权”和“执行权”：由统一的策略上下文（OrderDiscountContext）根据当前订单特征，明确选出唯一一个或一组待执行策略，然后调用其calculate()方法。选择逻辑本身可以是简单枚举匹配，也可以是复杂规则引擎（如Drools），但执行环节永远是干净的、无副作用的、幂等的。

至于状态模式（State Pattern），它适用于对象内部状态驱动行为变化的场景，比如订单状态从“待支付”到“已发货”时，cancel()方法的行为完全不同。但折扣计算不改变订单自身状态，它只是基于当前状态（已知的用户、商品、时间等快照）产出一个数值结果。强行套用状态模式，反而会让DiscountStrategy接口暴露一堆无意义的状态转换方法，违背单一职责。

2.2 核心类图与关键抽象：三个接口撑起整个体系

我们最终落地的结构非常精简，只有三个核心接口，却覆盖了所有扩展需求：

• DiscountStrategy：最顶层策略接口，定义所有折扣策略必须实现的契约。

  public interface DiscountStrategy { /** * 策略唯一标识码，用于配置中心映射和日志追踪 */ String code(); /** * 计算本策略可提供的折扣金额 * @param context 订单上下文，包含所有必要字段 * @return 折扣金额（正数），0表示不适用或不满足条件 */ BigDecimal calculate(OrderDiscountContext context); /** * 当前策略是否适用于该订单上下文 * 用于预筛选，避免无效计算 */ boolean matches(OrderDiscountContext context); }

• OrderDiscountContext：策略执行所需的全部上下文数据，采用不可变对象（Immutable）设计，杜绝策略间相互污染。

  @Value // Lombok生成构造、equals、hashCode public class OrderDiscountContext { BigDecimal originalAmount; // 订单原始总金额（未扣任何折扣） List<OrderItem> items; // 商品明细列表 User user; // 用户信息（等级、会员类型、历史行为标签） LocalDateTime orderTime; // 下单时间（用于时段活动） String regionCode; // 地域编码（用于区域限价） Map<String, Object> extraData; // 预留扩展字段，如设备ID、营销渠道来源 }

• DiscountStrategyFactory：策略工厂，负责根据code动态获取具体策略实例。这里我们没用简单的HashMap，而是结合Spring的ApplicationContext，实现真正的运行时装配：

  @Component public class DiscountStrategyFactory { private final Map<String, DiscountStrategy> strategyMap; public DiscountStrategyFactory(ApplicationContext context) { // 扫描所有实现了DiscountStrategy接口的Bean Map<String, DiscountStrategy> beans = context.getBeansOfType(DiscountStrategy.class); this.strategyMap = beans.entrySet().stream() .collect(Collectors.toMap( entry -> entry.getValue().code(), // key为策略code Map.Entry::getValue // value为策略实例 )); } public DiscountStrategy getStrategy(String code) { DiscountStrategy strategy = strategyMap.get(code); if (strategy == null) { throw new IllegalArgumentException("Unknown discount strategy code: " + code); } return strategy; } }

这个设计看似简单，但解决了最关键的两个问题：一是策略注册零侵入——只要新写一个类实现DiscountStrategy接口并加上@Component，Spring启动时自动注入工厂；二是上下文强隔离——每个策略拿到的都是同一份不可变快照，无法修改其他策略的输入，彻底规避了“张三策略改了user.vipLevel，导致李四策略计算错误”的经典并发陷阱。

2.3 为什么放弃硬编码策略映射，而选择配置中心驱动？

早期版本我们确实用过Map.of("FULL_REDUCTION", new FullReductionStrategy(), ...)硬编码。但上线两周后，运营提了一个需求：“双11期间，‘满199减20’规则临时升级为‘满199减30’，活动结束后恢复”。如果走代码发布，意味着要为一个数值改一次发版，成本太高。我们立刻切到了配置中心驱动模式。

核心改造点有三处：

1. 策略配置化：在Nacos配置中心新建dataIddiscount-strategy-config.yaml，内容如下：

   strategies: - code: FULL_REDUCTION_199 className: com.example.discount.strategy.FullReductionStrategy params: threshold: 199.00 reduction: 30.00 enabled: true priority: 10 - code: COUPON_DISCOUNT className: com.example.discount.strategy.CouponDiscountStrategy params: {} enabled: true priority: 5

2. 动态策略加载器：监听配置变更，解析YAML，通过反射创建策略实例，并注入参数（如reduction值），再注册进工厂的Map。
3. 策略启用开关：enabled字段控制该策略是否参与计算，比删代码安全一万倍。

实测效果：运营在配置中心修改reduction值，3秒内全量节点生效，无需重启，灰度验证只需改单个节点配置。这个改动让策略迭代周期从“天级”压缩到“秒级”，也让我们真正理解了策略模式的威力——它不仅是代码组织方式，更是业务敏捷性的基础设施。

3. 核心细节解析与实操要点：从接口定义到线程安全

3.1 DiscountStrategy接口的四个隐藏设计意图

别小看DiscountStrategy接口那三个方法，每一行都踩过坑：

• code()方法必须返回String，而非枚举
  初期我们用enum DiscountCode { FULL_REDUCTION, COUPON, ... }，看似类型安全。但当运营需要A/B测试时，要求“对50%用户启用新策略NEW_COUPON_V2”，这时枚举就得改源码加新值，破坏了“配置驱动”原则。改成String后，code可以是COUPON_V2#A这样的复合键，策略工厂按前缀路由，完全不碰代码。

• calculate()方法返回BigDecimal，且明确要求“正数”
  这是财务合规的铁律。我们曾因某个策略返回负数（表示“加价”），被风控系统误判为恶意刷单，冻结了2000+用户账户。现在强制约定：返回0表示不适用，正数表示折扣额，负数直接抛异常。同时在工厂层统一做校验：

  public BigDecimal calculate(String strategyCode, OrderDiscountContext context) { BigDecimal result = factory.getStrategy(strategyCode).calculate(context); if (result.signum() < 0) { // signum()返回-1,0,1 throw new IllegalStateException("Strategy " + strategyCode + " returned negative discount: " + result); } return result; }

• matches()方法不是可选，而是必填的性能守门员
  某次大促压测，TPS卡在1200上不去。Arthas火焰图显示calculate()方法占CPU 65%，深入一看，原来“新人专享”策略对所有订单都执行了完整计算，哪怕用户是VIP老客。后来我们强制要求所有策略必须实现matches()，并在主流程中前置过滤：

  List<DiscountStrategy> applicableStrategies = allStrategies.stream() .filter(strategy -> strategy.matches(context)) .sorted(Comparator.comparingInt(DiscountStrategy::priority)) // 按优先级排序 .collect(Collectors.toList());

  加上这层过滤，calculate()调用量下降78%，TPS飙升至4500。

• matches()必须是纯函数，禁止IO和远程调用
  有同学在matches()里查了Redis判断用户是否领过券，导致策略筛选变成网络瓶颈。我们立下规矩：matches()只能基于OrderDiscountContext已有字段做轻量判断（如context.getUser().getLevel() >= 3），所有外部依赖必须挪到calculate()里，并做好熔断降级。

3.2 OrderDiscountContext的不可变性与深拷贝陷阱

OrderDiscountContext声明为@Value（Lombok），表面看是不可变的。但List<OrderItem>和Map<String, Object>是引用类型，如果策略A修改了context.getItems().get(0).setPrice(...)，策略B就会拿到脏数据。我们最初没意识到这点，线上出现过“满减策略把商品价格改成了0，导致后续优惠券按0元计算”的事故。

解决方案分两步：

1. 构造时强制深拷贝：在Context构造方法里，对所有集合类做防御性拷贝：

   @Builder public OrderDiscountContext(BigDecimal originalAmount, List<OrderItem> items, User user, LocalDateTime orderTime, String regionCode, Map<String, Object> extraData) { this.originalAmount = originalAmount; this.items = items == null ? Collections.emptyList() : items.stream().map(OrderItem::copy).collect(Collectors.toList()); // copy()是OrderItem的深拷贝方法 this.user = user == null ? User.EMPTY : user.copy(); this.orderTime = orderTime; this.regionCode = regionCode; this.extraData = extraData == null ? Collections.emptyMap() : new HashMap<>(extraData); // 浅拷贝足够，extraData里不放可变对象 }

2. 运行时防护：在工厂的calculate()入口，用Byte Buddy字节码增强，在调用calculate()前，对Context所有集合字段做Collections.unmodifiableXXX()包装，一旦策略试图修改，立刻抛UnsupportedOperationException。这招在灰度期帮我们揪出了3个偷偷改Context的策略。

3.3 DiscountStrategyFactory的线程安全与Spring生命周期

工厂类看似简单，但有两个致命细节：

• strategyMap必须用ConcurrentHashMap
  虽然Spring Bean默认单例，但配置中心热更新时，会调用refreshStrategies()方法重建Map。如果用HashMap，多线程并发读写会触发ConcurrentModificationException。我们在线上见过一次，恰好发生在大促开始前10分钟，所有节点同时刷新，瞬间500错误率飙升。换成ConcurrentHashMap后，putAll()操作原子性得到保障。

• 工厂必须实现ApplicationRunner，确保策略加载在Spring容器就绪后
  早期有策略类依赖RedisTemplate，但工厂初始化时RedisTemplate还没创建好，导致NPE。通过实现ApplicationRunner，把策略加载逻辑放到run(ApplicationArguments args)里，完美解决依赖时序问题：

  @Override public void run(ApplicationArguments args) throws Exception { loadStrategiesFromConfig(); // 从Nacos加载 log.info("Loaded {} discount strategies", strategyMap.size()); }

4. 实操过程与核心环节实现：从零搭建可运行的折扣引擎

4.1 环境准备与基础依赖（Spring Boot 2.7.x）

我们基于Spring Boot 2.7.18（JDK 11）构建，核心依赖如下（pom.xml片段）：

<dependencies> <!-- Spring Web --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- Nacos配置中心 --> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> <version>2021.1</version> </dependency> <!-- Lombok --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <!-- Apache Commons Lang3（用于字符串工具） --> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> <version>3.12.0</version> </dependency> <!-- JUnit 5 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies>

提示：Nacos版本必须与Spring Cloud Alibaba对齐，2021.1对应Spring Boot 2.7.x。若用Spring Boot 3.x，请升级到2022.x版本，否则配置监听失效。

4.2 定义核心领域模型（精简但完备）

订单折扣涉及的最小必要模型只有三个，我们刻意避免过度设计：

• OrderItem（商品项）：

  @Data @Builder public class OrderItem { private Long skuId; private String skuName; private BigDecimal price; // 单价 private Integer quantity; // 数量 private String categoryCode; // 类目编码，用于品类折扣 // 深拷贝方法 public OrderItem copy() { return OrderItem.builder() .skuId(this.skuId) .skuName(this.skuName) .price(this.price) .quantity(this.quantity) .categoryCode(this.categoryCode) .build(); } }

• User（用户）：

  @Data @Builder public class User { private Long id; private Integer level; // 会员等级：1-普通，2-黄金，3-铂金，4-黑卡 private List<String> tags; // 行为标签：["new_user", "high_value"] private LocalDateTime registerTime; // 注册时间，用于新用户判断 public static final User EMPTY = User.builder().level(0).tags(Collections.emptyList()).build(); public User copy() { return User.builder() .id(this.id) .level(this.level) .tags(new ArrayList<>(this.tags)) .registerTime(this.registerTime) .build(); } }

• DiscountResult（折扣结果）：这是对外输出的DTO，必须清晰分离计算逻辑与展示逻辑。

  @Data @Builder public class DiscountResult { private BigDecimal totalDiscount; // 总折扣额 private List<DiscountDetail> details; // 各策略明细 @Data @Builder public static class DiscountDetail { private String strategyCode; // 策略编码 private String description; // 策略描述，如“满199减30” private BigDecimal amount; // 本策略折扣额 } }

4.3 编写第一个策略：满减策略（FullReductionStrategy）

这是最典型的策略，也是我们压测的基准线。代码必须体现策略模式的精髓——高内聚、低耦合、易测试：

@Component public class FullReductionStrategy implements DiscountStrategy { // 从配置中心注入的参数，支持热更新 private volatile BigDecimal threshold = BigDecimal.valueOf(199.00); private volatile BigDecimal reduction = BigDecimal.valueOf(30.00); // 构造时从Nacos配置注入 public FullReductionStrategy(@Value("${discount.full.threshold:199.00}") String thresholdStr, @Value("${discount.full.reduction:30.00}") String reductionStr) { this.threshold = new BigDecimal(thresholdStr); this.reduction = new BigDecimal(reductionStr); } @Override public String code() { return "FULL_REDUCTION"; } @Override public boolean matches(OrderDiscountContext context) { // 快速判断：原始金额是否达到阈值 return context.getOriginalAmount().compareTo(threshold) >= 0; } @Override public BigDecimal calculate(OrderDiscountContext context) { // 精确计算：折扣额不能超过原始金额 return context.getOriginalAmount().min(reduction); } // 供配置中心热更新调用 public void updateParams(BigDecimal threshold, BigDecimal reduction) { this.threshold = threshold; this.reduction = reduction; } }

注意：volatile修饰符保证参数更新对所有线程可见；updateParams()方法暴露给配置监听器，实现运行时调整。这个类没有一行代码依赖Spring容器，纯POJO，单元测试可直接new调用。

4.4 主计算引擎：OrderDiscountEngine的实现逻辑

这是整个系统的中枢，它不关心具体策略怎么算，只负责“选谁算、怎么组合、怎么兜底”：

@Service public class OrderDiscountEngine { @Autowired private DiscountStrategyFactory strategyFactory; @Autowired private DiscountRuleManager ruleManager; // 规则管理器，封装优先级、互斥逻辑 /** * 主计算入口 * @param context 订单上下文 * @return 折扣结果 */ public DiscountResult calculate(OrderDiscountContext context) { long start = System.currentTimeMillis(); // 步骤1：获取所有启用的策略 List<DiscountStrategy> allStrategies = strategyFactory.getAllStrategies(); // 步骤2：预筛选，排除明显不匹配的策略 List<DiscountStrategy> matchedStrategies = allStrategies.stream() .filter(DiscountStrategy::isEnabled) // 先看全局开关 .filter(strategy -> strategy.matches(context)) .collect(Collectors.toList()); // 步骤3：按优先级排序（高优先级先执行） matchedStrategies.sort(Comparator.comparingInt(DiscountStrategy::priority).reversed()); // 步骤4：执行策略，累积折扣 BigDecimal totalDiscount = BigDecimal.ZERO; List<DiscountResult.DiscountDetail> details = new ArrayList<>(); for (DiscountStrategy strategy : matchedStrategies) { try { BigDecimal amount = strategy.calculate(context); if (amount.compareTo(BigDecimal.ZERO) > 0) { totalDiscount = totalDiscount.add(amount); details.add(DiscountResult.DiscountDetail.builder() .strategyCode(strategy.code()) .description(getDescription(strategy.code())) .amount(amount) .build()); } } catch (Exception e) { // 策略内部异常不能影响整体，记录告警，跳过该策略 log.error("Strategy {} calculation failed for order {}", strategy.code(), context, e); // 可选：发送告警消息 alertService.send("StrategyCalculationFailed", strategy.code(), context); } } long cost = System.currentTimeMillis() - start; if (cost > 50) { // 超过50ms记录慢日志 log.warn("Discount calculation slow: {}ms, context={}", cost, context); } return DiscountResult.builder() .totalDiscount(totalDiscount) .details(details) .build(); } // 根据code获取策略描述，可对接配置中心或数据库 private String getDescription(String code) { return switch (code) { case "FULL_REDUCTION" -> "满199减30"; case "COUPON_DISCOUNT" -> "可用优惠券"; case "NEW_USER_BONUS" -> "新用户首单立减5元"; default -> "未知策略"; }; } }

这个引擎的关键设计点：

• 异常隔离：单个策略崩溃不影响整体，符合“故障降级”原则；
• 耗时监控：内置慢SQL式监控，超50ms自动告警，便于性能优化；
• 描述解耦：getDescription()方法独立，方便国际化或运营后台动态配置。

4.5 配置中心集成：Nacos YAML配置与监听器

在bootstrap.yml中配置Nacos：

spring: cloud: nacos: config: server-addr: 127.0.0.1:8848 file-extension: yaml group: DISCOUNT_GROUP namespace: dev

创建配置监听器，实现热更新：

@Component @RefreshScope // 开启配置刷新 public class DiscountConfigListener { @Autowired private DiscountStrategyFactory strategyFactory; @Value("${discount.full.threshold:199.00}") private String fullThreshold; @Value("${discount.full.reduction:30.00}") private String fullReduction; @EventListener public void handleContextRefresh(ContextRefreshedEvent event) { // Spring容器启动完成时，初始化策略参数 refreshFullReductionParams(); } @EventListener public void handleContextClosed(ContextClosedEvent event) { // 容器关闭时清理资源 } // 监听Nacos配置变更 @NacosConfigListener(dataId = "discount-strategy-config.yaml", groupId = "DISCOUNT_GROUP") public void onConfigChange(String config) { try { Yaml yaml = new Yaml(); Map<String, Object> configMap = yaml.load(config); // 解析并更新策略参数... refreshFullReductionParams(); } catch (Exception e) { log.error("Failed to parse discount config", e); } } private void refreshFullReductionParams() { FullReductionStrategy strategy = (FullReductionStrategy) strategyFactory.getStrategy("FULL_REDUCTION"); strategy.updateParams(new BigDecimal(fullThreshold), new BigDecimal(fullReduction)); } }

5. 常见问题与排查技巧实录：来自生产环境的23个真实案例

5.1 策略不生效的五大高频原因与定位步骤

我们整理了线上最常遇到的“策略明明配了却不生效”问题，按排查难度从低到高排序：

实操心得：我们给每个策略类加了@Validated注解，并在calculate()入口用@Valid校验context，一旦context字段为空，立即失败，避免静默错误。这招让80%的配置类问题在启动时就暴露。

5.2 折扣金额计算偏差：精度、舍入与财务对账

财务部门最敏感的是“一分钱差异”。我们曾因BigDecimal的setScale()用错，导致百万订单累计偏差237.51元。以下是必须死记的三条铁律：

1. 所有金额运算必须用BigDecimal，且构造函数禁用double
   错误：new BigDecimal(199.99)→ 实际值是199.98999999999998...
   正确：new BigDecimal("199.99")或BigDecimal.valueOf(199.99)

2. 舍入模式统一用RoundingMode.HALF_UP（四舍五入）
   财务系统默认此模式，Java中BigDecimal.ROUND_HALF_UP已废弃，必须用枚举：

   BigDecimal amount = baseAmount.multiply(rate) .setScale(2, RoundingMode.HALF_UP); // 保留2位小数

3. 最终折扣额必须与原始金额同精度
   如果订单金额是199.99（两位小数），折扣额必须也是两位小数，不能是30.000。我们封装了工具类：

   public static BigDecimal normalizeScale(BigDecimal value) { return value.setScale(2, RoundingMode.HALF_UP); }

   并在DiscountResult的@PostConstruct中强制调用。

5.3 性能瓶颈排查：从火焰图到GC日志

大促期间TPS从5000跌到800，Arthas火焰图显示FullReductionStrategy.calculate()占CPU 92%。深入分析发现，该策略每次调用都新建了ArrayList和StringBuilder，而QPS 2000时，每秒创建400万个对象，Young GC每秒2次。

优化方案：

• 对象池化：对List<OrderItem>这种高频集合，用ThreadLocal<List<OrderItem>>缓存；
• 字符串拼接：description字段改用String.format()预编译，避免运行时解析；
• 缓存计算结果：对“满减”这类纯数值计算，用Caffeine缓存{threshold,reduction}→result，命中率99.2%。

优化后，calculate()方法CPU占比降至3%，TPS重回5000+。

5.4 灰度发布与AB测试实战技巧

要上线“新人专享V2”策略，又怕影响老用户，我们用三步法实现零风险灰度：

1. 策略开关分级：在Nacos配置中增加grayRatio: 0.1（10%流量），grayUsers: [1001,1002]（白名单用户ID）；
2. 上下文增强：在OrderDiscountContext中增加isInGrayTraffic()方法，根据用户ID哈希取模或查白名单；
3. 策略路由：在DiscountStrategyFactory中，getStrategy()方法根据isInGrayTraffic()返回NEW_USER_V2或NEW_USER_V1。

这样，运营可以在配置中心随时调整灰度比例，技术无需发版，产品可实时看AB测试数据报表。

6. 扩展性设计与未来演进：从单体到规则引擎

6.1 当策略数量突破100，如何平滑过渡到Drools？

目前我们管理37个策略，一切良好。但当策略数破百，硬编码的matches()逻辑会变得难以维护。我们的演进路线图是：

• 阶段一（当前）：所有策略仍为Java类，matches()用简单条件判断；
• 阶段二（6个月后）：将复杂策略（如“连续7天登录用户，第8天下单享双倍积分”）迁移到Drools，Java策略只做轻量路由；
• 阶段三（1年后）：构建可视化规则编排平台，运营拖拽生成DRL文件，自动部署到规则引擎集群。

关键过渡技巧：保持DiscountStrategy接口不变。Drools规则封装成一个DroolsStrategy类，它实现DiscountStrategy，内部调用KieSession。对上层引擎完全透明，真正做到“策略即服务”。

6.2 多策略组合计算：叠加、互斥与优先级调度

现实业务中，“满减”和“优惠券”经常要叠加使用。我们设计了三层调度机制：

• 第一层：策略分组
  在配置中定义group: "COMBINATION"，引擎先按组聚合，再组内排序。

• 第二层：互斥规则
  @Exclusive(groups = {"COUPON", "POINTS"})注解，标记“优惠券”和“积分抵扣”互斥，同一订单只选其一。

• 第三层：叠加权重
  @Stackable(weight = 0.7)，表示该策略最多承担70%的折扣总额，避免某策略吃掉全部额度。

这套机制让我们在“双11跨店满减+品类券+店铺券”三重叠加场景下，计算准确率100%，财务对账零差异。

6.3 我个人在实际操作中的体会是...

写完这个系列的第一篇，我想说：策略模式不是银弹，它解决不了需求混乱、边界不清、职责模糊的问题。我们团队踩过的最大坑，不是技术实现，而是在没理清“哪些逻辑该放进策略，哪些该放在订单服务里”之前，就急着写代码。比如“用户是否满足新用户条件”，这个判断应该放在matches()里，还是由上游服务传入isNewUser: true/false？我们争论了三天，最后达成共识：策略只处理“基于已知事实的确定性计算”，所有需要查库、调远程服务的“不确定性判断”，必须由上下文提供。这个原则让我们的策略类平均只有87行代码，单元测试覆盖率98%，上线至今零P0事故。

如果你正在重构自己的折扣模块，我的建议是：先画一张表，列出所有现有规则，对每一行标注“输入字段”、“计算逻辑”、“输出结果”、“是否需查库”。凡是“是否需查库”列写“是”的，立刻踢出策略，交给订单服务预处理。剩下的，才是策略模式真正该发力的地方。