Go策略模式核心是窄接口、运行时安全切换、依赖注入；接口仅含1～2个导出方法（如Apply(amount float64) float64），禁用interface{}、全局变量和空壳方法，构造函数返回接口并校验参数，无状态用值接收+函数类型，有状态用指针接收+结构体。
Go 里策略模式不是“要不要用”的问题，而是“怎么用才不翻车”的问题。它在支付、折扣、日志格式化、路由规划等场景中天然适用，但直接照搬 Java 写法（比如一堆 ConcreteStrategyX 结构体 + 接口）反而会增加冗余和维护成本。
策略接口必须窄，且只含导出方法
接口定义越小越安全，比如 DiscountStrategy 只该有 Apply(amount float64) float64，别塞 Init()、Validate() 或 Config() *Config。这些额外方法会让所有实现都得写空壳，违反单一职责，也阻碍新增策略。
- 方法名首字母必须大写，否则其他包无法实现该接口
- 避免用
interface{}替代具体策略接口——它绕过编译检查，运行时调用Apply()就 panic - 别提前为“未来可能加”扩展接口；真需要时再改，Go 鼓励小接口迭代
优先用函数类型，结构体仅当需状态时才引入
纯算法逻辑（如 JSON 日志格式化、固定比例折扣）用函数类型更轻量：type LogFormatter func(msg string, fields map[string]interface{}) string。它零分配、易测试、可直接闭包捕获依赖。
- 结构体适合带状态的策略：比如一个带重试计数器的 HTTP 客户端，或缓存最近 10 次计算结果的运费计算器
- 若用结构体，构造函数应校验必要依赖（如
*http.Client是否为 nil），不在Apply()里现场初始化 - 值接收 vs 指针接收：无状态策略用值接收更安全；有状态必须用指针，否则修改不生效
运行时切换必须隔离实例，禁用全局变量
把策略存在全局变量里（var currentStrategy DiscountStrategy）是并发雷区。HTTP handler 中一改，所有 goroutine 共享同一实例，A 用户的折扣阈值可能被 B 用户覆盖。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法是将策略作为服务结构体字段，用
sync.RWMutex保护读写（尤其读多写少场景） - 如果策略启动后就固定（如从配置加载一次），用
sync.Once初始化即可，无需锁 - 别在构造函数里做耗时操作（如建 DB 连接、读大文件）——策略应轻量，依赖由上层注入
构造函数必须返回接口，而非具体类型
写 func NewAlipay(appID, key string) *Alipay 是典型错误。这导致调用方强依赖具体类型，换微信支付就得改所有 new 和赋值语句。
- 统一返回接口：
func NewAlipay(appID, key string) PaymentStrategy - 构造函数名保持 Go 社区习惯：全大写缩写（
NewWechatPay，非NewWeChatPay或MakeWechat） - 若初始化可能失败（如密钥校验不通过），返回
(PaymentStrategy, error)，别 panic
最容易被忽略的是状态污染——同一个策略实例被多个请求复用。哪怕只是加了个 retryCount int 字段，没做 request-scoped 隔离，就会出现 A 请求重试 3 次后，B 请求直接走 fallback 的诡异行为。
