核心是将状态判断交给策略对象自主完成，通过canHandle和execute双方法封装判断与执行逻辑，配合工厂动态选取策略，使业务代码彻底消除if/else。
核心是把“状态判断”从调用方剥离，交给策略对象自己决定是否响应，再由统一接口执行动作——多态负责行为分发，策略模式负责动态路由，两者结合后，业务主流程里不再出现任何 if、else 或 switch。
定义无判断逻辑的策略接口
接口只声明“能做什么”，不暴露“为什么做”或“依据什么做”。比如处理订单异常：
- 不要写
handle(String errorCode)—— 这会逼你在外面先解析errorCode再传入，判断逻辑仍在外部 - 要写
canHandle(TradeContext context)和execute(TradeContext context)—— 判断和执行都封装在策略内部 - 所有策略共用同一个上下文对象（如
TradeContext），包含订单号、错误码、金额、时间等字段，策略按需读取
让每个策略自主决定是否匹配
不同状态对应不同策略类，每个类只专注一种场景：
-
NoProcessorFoundStrategy：检查context.getErrorCode().equals("NO_PROCESSOR") -
ValidationFailedStrategy：检查context.hasValidationError() -
TimeoutStrategy：检查context.getElapsedMs() > 30000 - 新增状态？加一个新类，实现
canHandle和execute，不改任何已有代码
用工厂统一管理策略选取
避免手动维护 Map 时又写一遍 if-else：
立即学习“Java免费学习笔记（深入）”；
- Spring 环境下，所有策略类标注
@Service并实现标记接口（如OrderFailureStrategy） - 工厂类启动时调用
applicationContext.getBeansOfType(OrderFailureStrategy.class)拿到全部实例 - 执行时遍历所有策略，调用
canHandle(context)，找到第一个返回true的即刻执行execute(context) - 可加缓存优化：首次匹配成功后，将
context的关键特征（如错误码）与策略映射起来，后续直接查表
业务代码只剩一行调用
原来散落在各处的状态判断被彻底收口：
- 老写法：
if ("TIMEOUT".equals(code)) { handleTimeout(); } else if ("VALIDATION_FAIL".equals(code)) { handleValidation(); } - 新写法：
failureStrategyFactory.selectAndExecute(context); - 上下文对象承载全部必要信息，策略之间不共享状态，也不互相调用
- 测试时可单独注入某个策略，验证其
canHandle和execute行为，无需绕过分支逻辑
