策略模式通过接口统一算法契约，调用方仅依赖接口；定义清晰稳定的策略接口（如PaymentStrategy），各实现类独立封装逻辑且互不耦合；上下文持有接口引用并委托执行，客户端在运行时动态选择具体策略。

用接口实现策略模式，关键在于把变化的算法抽成统一契约，让调用方只依赖接口，不关心具体怎么执行。

定义策略接口：明确行为契约

接口是整个模式的起点，它声明所有策略必须提供的方法签名，不包含实现细节。比如支付场景中，只定义 pay(float amount)，不指定是微信还是支付宝——这一步决定了后续扩展是否干净。

• 接口名建议体现能力，如 PaymentStrategy、SortStrategy、OutboundStrategy
• 方法参数和返回值要稳定，避免频繁修改接口，否则所有实现类都要跟着改
• 可选添加辅助方法，例如 getStrategyType()，方便运行时识别当前策略

实现具体策略：各自封装独立逻辑

每个具体类实现同一接口，但内部逻辑完全隔离。支付宝走自己的验签流程，微信调自己的 SDK，JSON 外呼拼结构，XML 外呼加命名空间——彼此不耦合，也不继承彼此。

• 一个策略类只做一件事，比如 AlipayStrategy 不处理退款，只专注支付
• 策略类之间不应有依赖或调用关系，避免隐式绑定
• 如果策略需要外部资源（如 HTTP 客户端、配置），通过构造函数或 setter 注入，别硬编码

引入上下文类：统一调度与解耦调用

上下文不是策略本身，而是“策略的使用者”。它持有策略接口引用，把执行动作转交给当前策略，自己不写任何业务逻辑。

• 上下文通常提供 setStrategy() 或构造注入方式切换策略
• 对外暴露简洁方法，如 executePayment(amount)，隐藏策略切换细节
• 避免在上下文中做条件判断（如 if type == "alipay"），那会倒退回 if-else 反模式

客户端灵活选用：运行时决定行为

真正决定用哪个策略的，是客户端代码。它可以基于配置、用户选择、请求头、甚至 A/B 实验结果来设置策略，完全不影响上下文和其他策略。

• Spring 中可用 @Qualifier + 枚举映射自动装配对应策略 Bean
• 命令行工具可通过参数传入策略标识，再查表匹配实例
• Web 接口可从 query 或 body 读取 strategy=wechat，然后 set 对应对象