策略接口定义行为契约（如PaymentStrategy），具体策略类型实现接口方法，通过依赖注入在上下文中切换，避免硬编码和逻辑耦合，支持动态注册与生命周期管理。
什么是策略接口和具体策略类型
策略模式的核心是把算法的定义和使用分离，Golang 里用接口定义策略契约，用结构体实现具体行为。关键不是“多态”本身，而是让调用方不感知具体策略细节，只依赖 Do() 这类统一方法。
比如一个支付策略接口：
type PaymentStrategy interface {
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)
-
strategiesmap 的 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）。这点没想清楚，后面并发或资源泄漏就来了。
