Go中优先使用函数类型实现策略模式，如type LogFormatter func(string, map[string]interface{}) string，因其简洁、无调用开销、测试友好；仅当需维护状态时才用结构体+方法。
用函数类型还是接口？Go里优先选func
Go 里策略模式最轻量、最常用的方式，不是定义一堆 type Strategy interface，而是直接用函数类型。比如日志格式化：type LogFormatter func(string, map[string]interface{}) string。它比接口更简洁、调用无开销、测试时直接传闭包就行。
- 纯算法逻辑（无状态、不依赖外部配置）——一律用
func类型，别绕弯子写空结构体 - 需要维护状态（如限流器要记时间戳、重试器要存计数器）——才用结构体 + 方法，否则就是过度设计
- 接口只该描述“能做什么”，不是为了凑满一个“策略家族”而硬抽象；
interface{}更不行，它会让strategy.Execute()在运行时 panic
上下文怎么持有策略？避免 nil 和竞态
上下文（比如 PaymentContext 或 Order）通常持有一个策略字段，但直接裸写 strategy PaymentStrategy 容易出问题。
- 构造时必须检查是否为
nil，否则调用会 panic：在NewXXX(strategy)里加if strategy == nil { panic("strategy cannot be nil") } - 如果支持运行时热切换（比如根据用户等级动态换折扣策略），多个 goroutine 同时读写该字段会有竞态——得用
sync.RWMutex保护，或干脆放弃可变，改用WithStrategy()返回新实例 - 别在上下文里
import具体策略包（如alipay），否则一加新策略就得改上下文代码，违背解耦原则
策略怎么注册和加载？别硬编码 switch
真实项目中，策略往往来自配置（YAML/JSON）或请求参数，而不是写死在代码里。靠 map[string]Strategy 查表是最常见做法。
- 把所有策略实例提前注册进全局 map：
strategies["alipay"] = &Alipay{APIKey: cfg.Key} - 用工厂函数封装加载逻辑：
func NewStrategyFromConfig(name string) (PaymentStrategy, error)，返回具体实例，而非类型名 - HTTP API 场景下，可用请求头
X-Strategy: sha256动态选策略，避免每个 handler 写 if 判断 - 注意：map 的 key 建议小写+下划线统一风格（如
"credit_card"），别混用驼峰或空格，否则配置易错且难调试
什么时候不该用策略模式？警惕伪解耦
策略模式不是银弹。当策略之间共享大量逻辑、或只有微小差异（比如仅差一个参数），强行拆成多个结构体反而增加认知负担。
立即学习“go语言免费学习笔记（深入）”；
- 两个折扣策略只差一个系数（
0.1vs0.15）？直接用FixedDiscount{Rate: 0.15}结构体 + 字段就够了，不用搞三个独立类型 - 策略间需要频繁通信或共享缓存？说明它们本就属于同一责任域，可能该合并，而不是拆
- 新增策略频率极低（一年一次），且业务逻辑简单——if-else 更直白，别为模式而模式
真正值得上策略模式的，是那些你预见到未来半年内会新增两三种实现、且彼此完全正交的场景，比如支付渠道、日志后端、序列化格式。其他时候，先写清楚再重构。
