策略模式封装变量的多种计算逻辑以实现动态切换，适用于手续费、积分比率、库存阈值等高频变化场景，通过接口定义、策略实现与上下文注入解耦算法选择，避免if-else硬编码。
变量的策略模式不是操作“变量本身”，而是把针对同一变量（或同一类输入）的多种计算逻辑封装成可互换的策略，按需动态选用。关键不在变量怎么变，而在“怎么算它”可以灵活切换。
明确哪些变量计算适合用策略模式
不是所有变量都需要策略化。真正适合的，是那些计算规则随业务场景、用户类型、配置条件等高频变化
- 订单金额的手续费：按交易额比例、固定值、阶梯累进、免收——四种规则并存，且可能按商户等级启用不同组合
- 用户积分兑换比率：新用户1:1，老用户1:1.2，VIP用户1:1.5，且节假日临时上调至1:1.8
- 库存预警阈值：电商仓用“日均销量×7”，冷链仓用“保质期剩余天数≤3”，跨境仓用“在途时长+清关周期”
三步落地：定义接口、实现策略、注入上下文
以“手续费计算”为例，不写if-else，而是结构化组织：
-
定义统一策略接口：比如
FeeCalculator，只声明一个calculate(amount)方法，不关心内部怎么算 -
每个具体规则一个类：如
PercentageFeeStrategy（按5%）、FixedFeeStrategy（收3元）、HybridFeeStrategy（前1000免，超部5%） -
上下文持有并调用策略：比如
TransactionContext持有一个FeeCalculator实例，在创建交易时根据商户类型自动选配，或运行时通过配置中心热更新
让策略选择自动化，而不是硬编码
手动new PercentageFeeStrategy()就退化回了条件判断。真正实用的方式是解耦选择逻辑：
- 用策略工厂：传入
merchantType或region，返回对应策略实例，工厂内部可查Map或配置表 - 结合Spring @Qualifier或@Primary：多个策略Bean注册后，按注解或参数名自动注入
- 运行时从数据库/配置中心加载策略标识，反射或SPI加载对应类，支持不停机切换规则
注意边界：别把简单逻辑过度设计
策略模式解决的是多算法共存 + 频繁变更 + 需隔离维护的问题。如果只有两种固定规则，且几乎不会增删，直接用枚举+switch更轻量。策略的价值体现在新增一种手续费规则时，只需加一个类、改一行配置，不碰原有代码，也不重启服务。
