17370845950

策略接口定义行为契约（如PaymentStrategy），具体策略类型实现接口方法，通过依赖注入在上下文中切换，避免硬编码和逻辑耦合，支持动态注册与生命周期管理。

什么是策略接口和具体策略类型

策略模式的核心是把算法的定义和使用分离，Golang 里用接口定义策略契约，用结构体实现具体行为。关键不是“多态”本身，而是让调用方不感知具体策略细节，只依赖 Do() 这类统一方法。

比如一个支付策略接口：

type PaymentStrategy inte
rface {
    Pay(amount float64) error
}

两个实现：

type Alipay struct{}
func (a Alipay) Pay(amount float64) error {
    fmt.Printf("Alipay: %.2f\n", amount)
    return nil
}

type WechatPay struct{}
func (w WechatPay) Pay(amount float64) error {
    fmt.Printf("WechatPay: %.2f\n", amount)
    return nil
}

• 接口方法名必须一致，否则无法被同一上下文调用
• 结构体字段可为空（如上面的 Alipay{}），也可带配置（如 type StripePay struct { apiKey string }）
• 不要在接口里塞太多方法；一个策略接口通常只封装一类行为，比如只做 Pay，别混进 Refund 或 Query

如何在上下文中注入并切换策略

上下文（Context）不是必须叫 Context，它只是持有策略接口并调用其方法的结构体。策略实例应在创建上下文时传入，而不是在方法内硬编码或全局单例初始化。

type OrderProcessor struct {
    strategy PaymentStrategy
}

func NewOrderProcessor(s PaymentStrategy) *OrderProcessor {
    return &OrderProcessor{strategy: s}
}

func (o *OrderProcessor) Process(amount float64) error {
    return o.strategy.Pay(amount)
}

使用时可自由切换：

processor := NewOrderProcessor(Alipay{})
processor.Process(99.9)

processor = NewOrderProcessor(WechatPay{})
processor.Process(128.5)

• 避免在 NewOrderProcessor 内部用 switch 或配置判断选哪个策略——那又把逻辑耦合回去了
• 如果策略需初始化参数（如密钥、超时），应由调用方完成构造，再传给上下文，例如：NewOrderProcessor(NewStripePay("sk_test_..."))
• 不要在 Process 方法里做策略选择，那是上层业务逻辑该干的事

策略注册表 + 字符串驱动的动态选择

当策略数量变多、且需根据配置项（如 YAML 中的 payment_method: alipay）自动加载时，可以用 map 做简易注册表。注意这不是 DI 容器，只是避免 if/else 链。

var strategies = map[string]PaymentStrategy{
    "alipay":  Alipay{},
    "wechat":  WechatPay{},
    "stripe":  StripePay{apiKey: os.Getenv("STRIPE_KEY")},
}

func GetStrategy(name string) (PaymentStrategy, error) {
    s, ok := strategies[name]
    if !ok {
        return nil, fmt.Errorf("unknown strategy: %s", name)
    }
    return s, nil
}

然后结合上下文使用：

name := "alipay" // 来自 config 或 HTTP header
s, _ := GetStrategy(name)
p := NewOrderProcessor(s)
p.Process(199.0)

• strategies map 的 value 必须是具体策略值（Alipay{}）或指针（&Alipay{}），不能是未初始化的 nil 接口
• 注册表本身不解决策略间依赖（如日志、HTTP client），这些应通过构造函数参数注入到策略内部
• 如果策略初始化开销大（如建连接），注册表里存工厂函数更合适：map[string]func() PaymentStrategy

为什么不用函数类型替代接口

你确实可以用 type PayFunc func(float64) error，也简洁。但接口更适合策略模式，因为：

• 策略往往不止一个方法（比如还要 SupportCurrency() []string 或 MinAmount() float64），函数类型无法扩展
• 策略可能需要状态（如重试次数、token 缓存），结构体天然支持字段，函数闭包容易写乱
• 测试时，接口可轻松 mock；而函数类型要靠 func(...) 类型断言或包装，mock 框架支持弱
• IDE 跳转和文档提示对接口更友好——s.Pay(...) 点进去能看到所有实现，函数变量点进去只看到签名

函数类型适合一次性、无状态、单行为的场景；策略模式本质是“可插拔的有状态行为模块”，接口才是自然表达。

真正容易被忽略的是：策略的生命周期管理。比如一个 DatabaseBackupStrategy 持有 *sql.DB，它不该被多个上下文共享，也不该在每次 Process() 时新建——得看它是无状态（可复用）还是有状态（需每次 new）。这点没想清楚，后面并发或资源泄漏就来了。