Golang策略模式适合解决哪些问题_策略模式使用场景分析_技术教程

应使用 interface{} 定义策略当算法差异大、生命周期独立且不共享状态时，如支付方式；避
免将共用字段强塞入接口，宜用组合或工厂；策略应无条件判断，条件选择前置；函数类型无法携带状态和依赖，不利测试与维护；DI 与插件策略可分层处理。

什么时候该用 `interface{}` 定义策略而不是具体类型

当多个算法逻辑差异大、生命周期独立、且不共享内部状态时，用 interface{} 定义统一入口最稳妥。比如支付方式：PayMethod 接口只暴露 Process(amount float64) error，而 Alipay、WechatPay、CreditCard 各自实现，互不耦合。

反例是强行把带大量共用字段的结构体塞进策略接口——这时应该考虑组合或工厂封装，而非硬套策略模式。

策略间无共享字段或仅需极少量上下文（如 ctx context.Context）
新增策略不需改已有代码（符合开闭原则）
运行时可动态切换（如根据请求头 X-Payment-Method 选实现）

`switch` 分支太多？可能是策略没抽对粒度

常见错误：把「按用户等级打折」、「按商品类目打折」、「按促销活动打折」全塞进一个 DiscountStrategy 接口，结果每个实现里又写一堆 if 或 switch 判断条件——这说明策略边界模糊，不是策略模式用错了，是策略拆错了。

正确做法是让策略本身无条件判断，条件判断提前到选择策略的环节。例如：

func NewDiscountStrategy(userLevel string, category string, promoID string) DiscountStrategy {
    switch {
    case promoID != "" && isValidPromo(promoID):
        return &PromoDiscount{ID: promoID}
    case userLevel == "vip":
        return &VIPDiscount{}
    case category == "electronics":
        return &ElectronicsDiscount{}
    default:
        return &DefaultDiscount{}
    }
}

这样每个策略实现干净，职责单一，测试也容易覆盖。

为什么不用函数类型 `func(float64) error` 替代接口

函数类型轻量，适合极简场景（如日志格式化、简单校验），但策略模式真正价值在于「可携带状态 + 可依赖注入 + 可单元测试隔离」。用函数类型会丢失这些能力。

无法持有配置（如 StripeClient 实例）
无法在初始化时做连接池、缓存预热等操作
测试时难 mock（得靠闭包传依赖，易出错）
IDE 跳转和文档提示弱，维护成本高

例如，一个需要调用外部 API 的风控策略，必须是结构体+方法，而不是裸函数：

type RiskCheckStrategy struct {
    client *http.Client
    timeout time.Duration
}

func (r *RiskCheckStrategy) Check(orderID string) (bool, error) {
    // 使用 r.client 发起请求
}