策略模式通过接口封装可互换算法，实现“怎么做”与“谁来做”分离；定义统一策略接口和多个具体实现类，上下文持接口引用并委托执行，支持运行时切换；结合依赖注入可提升扩展性与测试性。

策略模式在C#中用于封装一组可互换的算法，让它们可以独立于使用它的客户端而变化。核心是把“怎么做”（算法）从“谁来做”（业务逻辑）中分离出来，通过接口统一行为，运行时动态切换具体实现。

定义策略接口与具体策略类

先声明一个公共策略接口，规定所有算法必须实现的方法；再为每种算法创建独立类，实现该接口。这样新增策略无需修改已有代码，符合开闭原则。

• 接口通常只包含一个核心方法（如Execute()），职责单一
• 每个具体策略类专注实现一种算法逻辑，不依赖其他策略
• 策略类通常是无状态的（不保存上下文数据），便于复用和线程安全

创建上下文类管理策略切换

上下文类持有一个策略接口的引用，提供设置和执行策略的入口。它不关心策略内部怎么实现，只负责委托调用。

• 构造函数或属性支持传入具体策略实例（推荐依赖注入方式）
• 可提供SetStrategy()方法在运行时更换策略
• 避免在上下文中写分支判断（如if-else选策略），把选择逻辑交给上层

在实际场景中应用策略模式

比如订单支付：微信支付、支付宝、银行卡支付可作为不同策略。客户端根据用户选择创建对应策略对象，传给支付上下文执行。

• UI层决定用哪种策略，new出对应实例（或由DI容器解析）
• 上下文调用strategy.Execute(order)完成支付，代码完全解耦
• 后续增加Apple Pay只需新增一个策略类，不改上下文和原有策略

配合依赖注入提升灵活性

在.NET Core/6+项目中，可将策略注册为服务，利用工厂模式或命名服务按需解析。

• 用IServiceCollection.AddKeyedSingleton("wechat")
• 上下文接收IEnumerable或Func工厂
• 运行时根据配置或参数获取对应策略，更易扩展和测试

基本上就这些。策略模式不复杂但容易忽略边界——比如策略间共享数据时，应通过上下文传参而非静态变量；多个策略共用部分逻辑，可提取基类或工具类，但别破坏策略的独立性。