Go策略模式核心是用窄接口或函数类型抽象行为，无状态优先函数类型，有状态用结构体+构造函数注入依赖，运行时切换须通过RWMutex保护字段或函数值赋值，禁用全局变量。
Go 语言没有类和继承，直接套用传统策略模式的 UML 图或 Java 写法会掉坑里——核心在于用接口 + 函数值/结构体字段组合，而不是“实现多个 Strategy 接口”。
如何定义可切换的策略接口
策略的本质是“行为抽象”，Go 里最自然的方式是定义一个函数类型或单方法接口。别写一堆 PayStrategy、LogStrategy 接口再各自实现；先看实际要换什么行为。
- 如果策略逻辑简单（比如不同排序规则），直接用函数类型：
type SortFunc func([]int) []int - 如果需要携带状态（如带超时配置的 HTTP 客户端策略），用结构体字段存依赖 + 方法实现行为：
type RetryStrategy struct { MaxRetries int; Backoff time.Duration }，再让其满足Do() error接口 - 避免为每个策略新建 interface：Go 的接口应由调用方定义（“鸭子类型”），不是由策略方提前声明
运行时切换策略的两种安全方式
切换不是靠 new 一个新对象然后赋值给全局变量——那是竞态根源。关键在“谁持有策略”和“何时变更”。
- 策略作为结构体字段，在初始化时注入：
service := &OrderService{payment: &AlipayStrategy{}}，后续通过导出方法替换：service.SetPayment(&WechatStrategy{})，且该方法内部加sync.RWMutex - 更轻量的做法是用函数值字段：
type Processor struct { handle func(string) error }，直接赋值：p.handle = func(s string) error { return strings.Contains(s, "v1") }，无锁、无同步开销 - 绝对不要在 goroutine 中直接修改未加锁的策略字段，否则会出现部分请求走旧逻辑、部分走新逻辑的混合行为
常见错误：把策略当成配置来 reload
看到 “切换” 就想监听文件或 etcd 变更然后热更新策略？这容易忽略策略本身的线程安全性与生命周期管理。
立即学习“go语言免费学习笔记（深入）”；
- 配置变更 ≠ 策略实例可安全替换：比如一个
DBStrategy持有*sql.DB连接池，直接替换会导致旧连接池被丢弃但未关闭，引发泄漏 - 若真需动态加载，策略类型必须实现
Close() error，并在切换前显式调用旧策略的Close - YAML 配置里写
strategy: "redis_cache"没问题，但解析后不能直接字符串匹配去 new 结构体——要用工厂函数映射：strategies["redis_cache"] = func() Strategy { return &RedisCacheStrategy{} }
策略切换最难的不是语法，而是厘清“策略实例的生命周期是否与业务请求耦合”。比如一个 HTTP handler 里每次请求都 new 一个策略，那根本不需要切换；而一个长周期运行的后台 worker，策略变了就得确保正在执行的任务不受影响——这才是真正要设计的地方。
