switch分支难维护因硬编码逻辑、违反开闭原则、可读性差；策略模式通过分离算法选择与实现、每种行为独立成类来解决，新增类型只需添加实现类并注册，调用处无需修改。
为什么 switch 分支难维护，而策略模式能解决它
因为 switch 把所有分支逻辑硬编码在一个方法里，每次新增类型就得改这个方法，违反开闭原则；同时类型判断和业务逻辑混在一起，可读性差、测试困难。策略模式把“选哪个算法”和“算法怎么实现”拆开，让每种行为独立成类，新增类型只需加一个实现类 + 注册，原调用处完全不动。
Strategy 接口定义要满足什么条件才好扩展
接口必须只暴露行为契约，不暴露实现细节或状态依赖。常见错误是把入参设计得太具体（比如塞进整个 Order 对象），导致策略类被迫处理无关字段；或者返回值类型太泛（如 Object），下游还得强转。
- 参数尽量精简：只传策略真正需要的数据，例如
calculateDiscount(double amount, String userType) - 返回值明确：用具体类型（
BigDecimal、Result<t></t>）而非Object或void - 避免在接口中定义生命周期方法（如
init()、destroy()），那是上下文或框架该管的事
StrategyFactory 缓存策略对象时要注意状态泄漏
如果策略类里有成员变量（比如缓存计数器、临时上下文引用），直接用 static Map 缓存单例会导致并发问题或脏状态复用。无状态策略可以安全共享，但有状态的必须每次新建。
- 无状态策略：构造函数空、所有方法仅依赖入参，可预实例化并缓存到
Map<string strategy></string> - 有状态策略：含
private int retryCount或private ThreadLocal<context></context>等，工厂中必须用new ConcreteStrategyX()每次创建 - Spring 场景下，推荐用
@Scope("prototype")配合@Qualifier注解注入，比手写工厂更可控
如何让客户端代码彻底摆脱 if-else 和 type 字符串硬编码
核心是把类型标识从字符串升级为编译期可检查的契约。直接用 "A"、"B" 作 key，容易拼错且 IDE 不提示；换成枚举或策略类 Class 对象，就能利用类型系统兜底。
- 用枚举替代字符串：定义
enum PayType { ALIPAY, WECHAT, BANK }，工厂接收PayType而非String - 用 Class 作 key：注册时用
strategies.put(AlipayStrategy.class, new AlipayStrategy())，调用时传AlipayStrategy.class，零字符串风险 - Spring Boot 中可结合
@ConditionalOnProperty或配置中心动态启用/禁用某策略，但注册入口仍需静态明确
strategy.doX() → service.updateY() → strategy.doZ() 这种循环依赖，就说明职责没切干净，后续加日志、事务、重试都会变得异常脆弱。
