策略模式通过定义语义清晰、职责单一的接口（如notificationstrategy）统一入口，各实现类（如smsnotificationstrategy）专注渠道特有逻辑，spring自动装配+类型匹配实现解耦分发，主流程简化为strategy.send(context)。
接口是策略模式的骨架，它把“做什么”明确下来，让所有分支行为有统一入口，从而把原本散落在 if-else 或 switch 里的判断逻辑，转为面向对象的“选哪个实现来干”。关键不在接口本身多复杂，而在它是否精准表达了业务意图、是否足够稳定、是否隔离了变化。
定义语义清晰、职责单一的策略接口
接口名和方法名要直说业务动作，比如 NotificationStrategy 而不是 Handler，方法叫 send() 或 apply() 而不是 execute()。参数尽量收进一个上下文对象（如 NotificationContext），避免塞一堆原始类型或 Map。返回值统一用封装结果（如 SendResult），不抛异常也不返回 null。
- 不暴露渠道细节：接口里不要出现 “getAccessToken()”、“buildUrl()” 这类只属于某一种实现的逻辑
- 不绑定识别逻辑：接口不负责判断“我能不能处理”，那是上层或策略自己 canHandle() 的事
- 不掺杂公共流程：日志、校验、事务这些通用动作，留在调用方或模板方法里，接口只管核心差异点
每个分支对应一个独立实现类，且彼此无依赖
原来 if 分支里的代码块，现在变成一个类：SmsNotificationStrategy、EmailNotificationStrategy、WeComNotificationStrategy。每个类只专注一件事——把上下文转化成该渠道能理解的请求，并调用对应网关。它们之间不 import 彼此，也不共享字段，测试时可单独 mock 网关，覆盖全部路径。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 类名带业务含义，一眼看出它负责什么场景
- 内部不写 if-else：如果某个策略内部还嵌套判断，说明它没拆干净，得再下沉一层
- 保持无状态：不持有外部变量或连接池，有状态资源按需创建或由 Spring 管理生命周期
用 Spring 自动装配 + 类型匹配替代硬编码分发
别在业务方法里写一长串 if ("SMS".equals(type)) new SmsStrategy()。启动时让 Spring 扫描所有 NotificationStrategy 实现，放进 Map
- 新增渠道？加个新类 + @Service 注解，其他代码完全不动
- 想支持运行时动态选择？让每个策略实现 canHandle(NotificationContext)，遍历匹配，更灵活也更安全
- 避免用反射或字符串拼类名，IDE 跳转、编译检查、单元测试都更友好
保留必要的守卫逻辑，但让它待在该在的地方
策略模式不追求消灭所有 if，而是让 if 出现在合理位置。比如参数非空校验、消息状态合法性检查，应该放在调用入口；而某个策略内部做“金额是否超限”“模板是否存在”，就属于它自己的职责范围。主流程最终只剩一行：strategy.send(context)，干净、易读、易测。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
