策略模式通过分离“选策略”与“执行逻辑”，用统一接口和多态分发消除运行时类型判断；每种业务分支对应独立实现类，新增类型只需添加类并注册，主流程仅一行调用。
策略模式不是用来“替换” if-else 的语法糖，而是把“该用哪个逻辑”和“这个逻辑怎么执行”彻底分开。只要分支依据是运行时可变的业务类型（比如支付方式、导出格式、错误响应策略），就适合用它来拔掉 if-else 的根。
定义统一策略接口，只暴露行为契约
先别写任何具体实现，而是聚焦在“它们共同要做什么”。例如处理订单失败后的动作，不管是什么错误，都该有一个 resolve() 或 applyTo(order) 方法：
- 接口不包含 type 字段、不暴露 instanceof 判断点
- 方法签名体现共性：如 void handle(Order order, ErrorContext context)
- 子类只负责“自己该怎么干”，不关心“别人怎么干”
为每种分支场景编写独立策略实现类
每个 if 分支对应一个策略类，完全解耦。比如原来有三类错误判断：
- NoProcessorFoundError → RetryableStrategy：设置重试状态 + 记录告警
- ValidationFailedError → RejectedStrategy：标记拒绝 + 返回结构化错误码
- UnknownError → FailedStrategy：统一设为失败 + 触发熔断指标
新增一种错误？只需加一个新类，实现接口，不碰原有任何代码。
用工厂或注册表统一调度，主流程只剩一行调用
把策略创建逻辑集中管理，避免业务层再出现 switch 或 if 查找：
- 初始化时用 Map
注册所有策略，key 可以是错误类型名、事件 code、配置标识等 - 主处理器中：HandlerStrategy strategy = registry.get(errorCode); strategy.handle(order, ctx);
- 若需动态加载，可用 ServiceLoader（Java）或 require.context（前端）配合约定命名自动发现
配合多态分发，让类型自己说话
策略模式真正生效的前提，是调用方不再做类型判断。关键一步是：让错误对象自身携带策略能力，或者让上下文持有策略实例：
- 错误类实现 handle(Event event) 方法，由子类决定如何影响状态
- EventProcessor 不再写 if (e instanceof X) { ... }，只调 e.handle(event)
- 这样 instanceof 就从 10 处变成 0 处，扩展新错误类型时，连注册表都不用改——只要它实现了接口
