策略接口必须是值类型安全的，即定义明确接口（如PaymentStrategy），所有实现均满足该接口，避免使用interface{}导致类型断言失败；构造函数应返回接口而非具体类型，确保可替换性；策略需无状态或隔离上下文，防止跨请求状态污染；测试应使用手工mock实现，聚焦行为选择而非网络调用。
策略接口定义必须是值类型安全的 interface{}
Go 没有传统 OOP 的抽象类或虚函数，策略模式靠接口实现，但接口变量本身不是“策略容器”——它只是契约。如果你把策略实现存进 map[string]interface{} 或 []interface{}，后续调用时容易触发 panic：类型断言失败或方法不存在。
正确做法是定义一个明确的策略接口，所有实现都满足它：
type PaymentStrategy interface {
Pay(amount float64) error
}
然后让 CashPayment、Alipay、WechatPay 都实现这个接口。别图省事用空接口 + 反射去“动态调用”，那不是解耦，是埋雷。
- 接口方法名和参数要稳定，比如别在
Pay()里突然加ctx context.Context—— 否则所有实现都要改，策略就失去可插拔性 - 如果策略需要配置（如 API key、超时时间），建议通过构造函数传入，而不是在
Pay()里硬编码或读全局变量 - 避免让策略接口依赖具体结构体，否则单元测试时 mock 成本高；优先用组合而非继承
strategy.NewXXX() 构造函数要返回接口，不是具体类型
常见错误是写 func NewAlipay() *Alipay，然后业务层直接 new 一个 struct 赋值给策略变量。这会导致调用方感知具体类型，破坏替换能力——一旦想换成 UnionPay，就得改所有 new 和赋值语句。
立即学习“go语言免费学习笔记（深入）”；
应该统一返回接口：
func NewAlipay(appID, privateKey string) PaymentStrategy {
return &alipayImpl{appID: appID, privateKey: privateKey}
}
这样上层只认 PaymentStrategy，切换策略只需改一行初始化代码，不碰业务逻辑。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 构造函数名统一用
NewXXX，别混用Make、Create或驼峰缩写（如NewAliPay），Go 社区习惯是全大写缩写保持一致 - 如果策略初始化可能失败（如密钥校验），返回
(PaymentStrategy, error)，别 panic —— 上游需要知道“策略不可用”，而不是崩溃 - 不要在构造函数里做耗时操作（如 HTTP 预连接、文件读取），策略应是轻量、无状态（或状态可控）的
运行时策略切换必须隔离上下文，不能共享 struct 实例
策略对象通常带状态（比如一个 retryCount 字段），如果多个请求共用同一个策略实例，就会相互干扰。典型现象是：A 用户支付失败重试了 2 次，B 用户一上来就触发第 3 次重试直接失败。
解决方式很简单：每次请求新建策略，或用工厂封装生命周期。
type StrategyFactory struct {
cfg Config
}
func (f *StrategyFactory) Get(strategyName string) (PaymentStrategy, error) {
switch strategyName {
case "alipay":
return NewAlipay(f.cfg.AlipayAppID, f.cfg.AlipayKey), nil
case "wechat":
return NewWechatPay(f.cfg.WechatAppID), nil
default:
return nil, fmt.Errorf("unknown strategy: %s", strategyName)
}
}
- 别把策略存在全局变量或单例里，尤其 Web 服务中，goroutine 不共享内存，但共享全局变量
- 如果策略需要复用底层资源（如 HTTP client、DB 连接池），把这些资源作为依赖注入到策略内部，而不是由策略自己创建
- HTTP handler 中别直接
factory.Get(r.URL.Query().Get("method"))，先校验再调用，防止恶意传参导致 panic
测试策略切换时，mock 接口比打桩 http.Client 更有效
很多人测策略模式时，绕不开真实支付网关，结果测试变慢、不稳定、还污染沙箱环境。其实策略的核心是“行为选择”，不是“网络调用”。
直接为 PaymentStrategy 写 mock 实现即可：
type MockSuccessStrategy struct{}
func (m MockSuccessStrategy) Pay(amount float64) error {
return nil
}
type MockFailStrategy struct{}
func (m MockFailStrategy) Pay(amount float64) error {
return errors.New("mock payment failed")
}
然后在测试里切换这两个 mock，验证主流程是否按预期走不同分支。
- 不用第三方 mock 工具（如 gomock），纯手工 mock 更轻、更可控，也更符合 Go 的务实风格
- 每个策略实现的单元测试，只覆盖它自己的逻辑；策略切换逻辑（如 factory）单独测，两者边界要清晰
- 集成测试才需要真实网关，但应放在 CI 的独立阶段，且用
testing.Short()控制跳过
策略模式真正的复杂点不在“怎么写接口”，而在于“谁来决定用哪个策略”以及“策略状态是否跨请求泄漏”。这两处没想清楚，代码看着解耦，实则更难维护。
