策略接口应只定义纯行为契约，共享依赖通过构造函数注入；避免空实现、全局变量并发写、硬编码路由及nil指针调用，推荐注册表+工厂函数+读写锁保障安全。
策略接口定义要避免空实现陷阱
Go 没有抽象类，靠接口模拟策略基类时，常见错误是把所有策略共用的字段（比如配置、日志器）塞进接口，导致每个实现都得重复写 func (s *A) Logger() *log.Logger 这类无意义方法。这违背策略模式“只关注算法差异”的本意。
正确做法是把共享依赖通过构造函数注入，策略接口只保留纯行为契约：
type PaymentStrategy interface {
Pay(amount float64) error
}然后让具体策略持有外部传入的依赖：
type Alipay struct {
client *alipay.Client
logger *log.Logger
}
func NewAlipay(c *alipay.Client, l *log.Logger) *Alipay {
return &Alipay{client: c, logger: l}
}
func (a *Alipay) Pay(amount float64) error { /* 实际逻辑 */ }- 接口方法必须是导出的（首字母大写），否则无法被其他包实现
- 不要在接口里定义
Init()或Close()——那是生命周期管理，不属于策略契约 - 如果策略需要初始化参数，统一走构造函数，别用 setter 方法
运行时策略切换不能靠全局变量硬编码
很多人用 var currentStrategy PaymentStrategy 全局变量 + SetStrategy() 函数来切换，看似简单，但并发下会 panic：多个 goroutine 同时写这个变量，且没有同步机制。
立即学习“go语言免费学习笔记（深入）”；
更安全的做法是把策略作为服务的一部分，封装在结构体中，并用 sync.RWMutex 保护读写：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type PaymentService struct {
mu sync.RWMutex
stra PaymentStrategy
}
func (p *PaymentService) SetStrategy(s PaymentStrategy) {
p.mu.Lock()
defer p.mu.Unlock()
p.stra = s
}
func (p *PaymentService) Process(amount float64) error {
p.mu.RLock()
defer p.mu.RUnlock()
return p.stra.Pay(amount)
}- 读多写少场景下，
RWMutex比Mutex性能更好 - 切忌在 HTTP handler 里直接修改全局策略变量——一个请求改了，所有后续请求都受影响
- 如果策略切换频率极低（如启动时定死），用
sync.Once初始化即可，无需锁
策略注册表要支持按条件动态路由
真实业务中，策略不是手动 SetStrategy() 切换的，而是根据订单类型、用户等级、地区等条件自动选。硬编码 if order.Type == "vip" { useVIPStrategy() } 很快会失控。
建议用 map + 函数做轻量注册表：
var strategyMap = make(map[string]PaymentStrategy)
<p>func RegisterStrategy(key string, s PaymentStrategy) {
strategyMap[key] = s
}</p><p>func GetStrategy(key string) (PaymentStrategy, bool) {
s, ok := strategyMap[key]
return s, ok
}调用时：
if s, ok := GetStrategy(order.PaymentMethod); ok {
return s.Pay(order.Amount)
}- key 建议用常量定义（如
const AlipayKey = "alipay"），避免字符串拼错 - 注册时机放在
init()或应用启动时，别在 handler 里反复注册 - 不推荐用反射自动扫描策略——增加编译复杂度，且 IDE 跳转和静态检查失效
接口实现要警惕 nil 指针调用 panic
策略对象未初始化就调用方法，比如 var s PaymentStrategy; s.Pay(100)，会直接 panic: “nil pointer dereference”。这不是策略模式的问题，是 Go 接口值为 nil 时，其底层 concrete value 也是 nil，方法调用即解引用空指针。
防御方式很简单：在关键入口加非空检查，或用工厂函数兜底：
func NewPaymentStrategy(method string) (PaymentStrategy, error) {
switch method {
case "alipay":
return NewAlipay(client, logger), nil
case "wechat":
return NewWechatPay(client, logger), nil
default:
return nil, fmt.Errorf("unknown payment method: %s", method)
}
}- 永远不要假设调用方传来的策略一定非 nil——尤其跨包或从配置加载时
- 错误返回比 panic 更可控，上层可统一降级（如切到默认策略）
- 单元测试里一定要覆盖
nil策略传入场景
策略模式本身不复杂，难点在于边界控制：什么时候该由策略决定，什么时候该由上下文兜底，以及并发下的状态一致性。这些地方没约束好，运行时切策略反而变成最不稳定的单点。
