策略模式通过分离判断与执行逻辑解决硬编码分支难维护问题，主流程调用统一接口，由工厂按参数动态切换具体策略，支持配置热更新、灰度发布与自动降级。
因为面向对象设计模式，特别是策略模式，把“判断逻辑”和“执行逻辑”彻底剥离开——判断归判断，执行归执行，不再挤在同一个方法里反复堆 if-else 或 switch。
硬编码分支为什么难维护
当业务规则一变，就得改代码；新增一种类型，就得加一个 else if；判断依据来自配置或外部输入，还得同步改一堆 case。这种写法让主流程越来越臃肿，测试难覆盖，上线风险高。
- 每次改优惠规则都要动核心结算方法
- 扫码渠道从微信扩展到抖音、小红书，就得往 switch 里塞新 case
- 风控策略按城市动态调整，但判断逻辑写死在服务类里，没法热更新
策略模式怎么做到“零修改主流程”
它不靠改代码来应对变化，而是靠“换策略”：主流程只负责调用统一接口，具体哪个策略生效，由工厂或上下文根据参数决定。
- 定义一个轻量接口，比如 PromotionStrategy，只声明一个 execute(Order order) 方法
- 每种折扣写成独立类：FullReductionStrategy、VipDiscountStrategy、FestivalStrategy，各自实现自己的逻辑
- 工厂按订单类型、用户等级等参数返回对应策略实例，主流程无感切换
配套机制让策略真正可用
单有策略类还不够，得配上支撑能力，才能落地：
- 策略自带 selfDescribe()，返回适用条件和版本信息，方便排查和灰度发布
- 工厂监听 Apollo/Nacos 配置，规则变了，策略自动刷新，不用重启服务
- 共享逻辑（如日志、幂等校验）抽成独立服务，构造器注入，避免策略间耦合
- 加降级策略和监控埋点，某个策略异常时自动 fallback，不影响整体链路
什么情况下该上策略模式
不是所有 if 都值得重构，但出现这三类信号，就该动手了：
- 业务规则每月一调，比如营销活动、计费模型频繁变更
- 新老逻辑并存，比如 AB 测试、灰度发布、兼容旧版履约路径
- 判断依据来自外部，比如扫码内容、错误类型、地域编码等运行时数据
