核心原因：同一件事（推荐），不同的端有不同的做法，而且"做法"会增减、会切换。如果不用策略模式，路由处会变成这样：// 反例：if-else 地狱 public MapString,Object recommend(UnifiedContext ctx) { String client = ctx.getDivinerVO().getClientInfo().getClient(); if ("wxa".equals(client)) { // 微信小程序：拉数据 A、组装协议 A...（几十行） } else if ("m".equals(client)) { // M 站：拉数据 B、组装协议 B...（几十行） } else { // APP：拉数据 C、组装协议 C...（几十行） } }这样的问题：违反开闭原则——每加一个端，就要回来改这个核心方法，碰一次就有把别的端改崩的风险。职责混在一起——"选哪个端"和"每个端怎么做"耦合在一个方法里，越来越长、没法测。不能热切换——灰度放量、按 source 切流都得改代码发版。用策略模式后，这三点全部解决：每个端是一个独立策略类（WxBffRecommendDelegate 等），互不影响，可单独测；加新端 = 新增一个类，核心路由代码一行不改；选哪个策略的规则放在 DUCC 配置里，运行时可热切。一个最简单的策略模式例子以"订单促销折扣计算"为例——不同活动有不同算法，但调用方只想说"算个价"。// 1. 策略接口：定义"做什么" public interface DiscountStrategy { BigDecimal apply(BigDecimal price); } // 2. 具体策略：各自实现"怎么做" public class NoDiscount implements DiscountStrategy