策略接口应仅定义行为契约，用canHandle(TradeContext)由策略自主判断，统一入参为上下文对象，避免含业务细节的签名；Spring中通过@Service+getBeansOfType自动注册，禁用@Component；策略需细粒度拆分、禁止内部嵌套if-else；异常必须显式抛出并分类。
策略接口怎么设计才不会后期爆炸
策略模式的核心不是写一堆 if-else，而是让条件判断“消失”——前提是接口定义得足够稳定。一旦把业务细节（比如状态码、渠道名、金额阈值）塞进接口方法签名，后续每加一个策略就得改接口，所有实现类跟着编译报错。
正确做法是：接口只暴露行为契约，不暴露判断依据。比如用 canHandle(TradeContext context) 让每个策略自己决定是否响应，而不是靠外部传 String type 再用 switch 分发。
- 避免在接口里定义
handle(String type, BigDecimal amount)这类带具体参数的签名 - 统一入参用上下文对象
TradeContext，包含订单号、渠道、金额、时间等字段，策略内部按需读取 - 接口方法返回
void或Result，别返回boolean表示“执行成功”，那是职责错位
Spring里怎么自动注册策略又不漏掉新实现
手动维护 Map<string paystrategy></string> 是最常见翻车点：新加一个 AlipayStrategy，忘了往容器里 put，线上直接 NullPointerException。
用 Spring 的 @Service + 接口泛型扫描最稳。声明一个标记接口 PayStrategy，所有实现类加 @Service，启动时用 ApplicationContext.getBeansOfType(PayStrategy.class) 拿全量实例，再通过 canHandle() 动态路由。
立即学习“Java免费学习笔记（深入）”；
- 别用
@Component—— 它不参与类型匹配，getBeansOfType找不到 - 如果策略需要区分环境（如测试/生产走不同支付通道），用
@Profile而不是在canHandle里硬编码"dev".equals(env) - 避免在构造器里做耗时操作（如加载配置文件），策略实例应轻量，初始化延迟到第一次
handle()调用
为什么用了策略模式还出现 if-else 嵌套
典型症状：策略类内部又写了三层 if (context.getAmount() > 100 && context.getChannel().equals("wx")) { ... } —— 这说明策略粒度太粗，没真正拆开关注点。
策略不是“按渠道分”，而是“按支付能力分”：比如 LowAmountPayStrategy 处理小额免密，HighRiskPayStrategy 处理大额风控校验。判断逻辑下沉到策略内部，上层只剩一行 strategy.handle(context)。
- 每个策略类只解决一个明确问题，方法体不超过 20 行
- 共用逻辑（如日志、幂等校验）抽成工具类，别在每个策略里重复写
log.info("start handle...") - 如果发现两个策略共享大量字段或方法，说明它们本该是一个策略里的不同分支，或者需要引入模板方法模式
策略执行失败时怎么避免静默吞异常
很多团队把策略包装成“兜底黑盒”，try-catch 住所有异常然后 return null，结果下游拿不到错误码，监控也看不到失败率，问题拖到资损才暴露。
策略的异常必须显式抛出，由调用方决定重试、降级或告警。约定所有策略实现类只抛两种异常：BusinessException（业务拒绝，如余额不足）和 SystemException（系统故障，如支付网关超时）。
- 禁止在策略里
catch (Exception e) { log.error(...); return; } - Spring AOP 可以统一拦截
SystemException发送企业微信告警，但别拦截BusinessException - 单元测试必须覆盖策略抛异常的路径，验证是否被正确捕获和分类
策略模式真正的难点不在结构，而在于“谁该判断、谁该执行”的权责切分——切歪了，if-else 就只是从 Controller 搬到了 Strategy 里。
