Go中用函数类型实现策略模式更轻量，因无需定义接口和struct、支持闭包捕获状态、测试简单且性能相当；但需注意nil检查、类型严格匹配及map动态调用的panic风险。
Go 里用函数实现策略模式，比接口更轻、更直接，只要类型匹配就能替换，不用写一堆 struct 和方法。
为什么用 func 类型代替接口定义策略
接口方式要先定义 DiscountStrategy 接口，再为每个策略写 struct + 方法实现；而函数类型直接把行为抽象成值，比如 type DiscountFunc func(float64) float64，所有折扣逻辑就是个函数，传进来就能用。
- 少写 boilerplate：不用声明空 struct、不用实现方法签名、不用调用
SetStrategy - 闭包友好：可捕获上下文（如会员等级阈值、有效期），接口实现反而要靠字段存状态
- 测试更简单：直接传一个匿名函数做 mock，不用构造具体策略实例
- 性能无差异：函数值本质是代码指针+闭包环境，和接口动态调度开销基本一致
DiscountFunc 类型如何定义和使用
关键不是“怎么声明”，而是“怎么让结构体持有它并安全调用”。常见错误是忽略 nil 检查或类型不匹配。
- 定义类型：
type DiscountFunc func(amount float64) float64 - 结构体字段必须显式声明为该类型：
discount DiscountFunc，不能只写func(...) - 调用前务必判空：
if o.discount == nil { return amount }，否则 panic - 赋值时类型必须严格一致：传
func(float32) float32会编译失败，Go 不自动转换
示例：
立即学习“go语言免费学习笔记（深入）”；
type Order struct {
total float64
discount DiscountFunc
}
<p>func (o *Order) GetFinalPrice() float64 {
if o.discount == nil {
return o.total
}
return o.total - o.discount(o.total)
}</p><p>// 使用
vipDiscount := func(amount float64) float64 { return amount * 0.15 }
order := &Order{total: 1000, discount: vipDiscount}
fmt.Println(order.GetFinalPrice()) // 850
运行时从 map 动态选策略的陷阱
很多人想用 map[string]DiscountFunc 实现“字符串驱动策略切换”，但容易掉进两个坑：类型擦除和 key 不存在时 panic。
- map 声明必须带完整函数签名：
map[string]DiscountFunc，不能写map[string]interface{}后强转 - 访问 map 时要用双返回值语法：
fn, ok := strategies["vip"]; if !ok { ... }，否则 key 不存在会得到 nil 函数，一调就 crash - 注册策略时别漏掉赋值：常见错误是写了
strategies["vip"] = nil，没检查就用了 - 避免全局 map 竞态：如果多 goroutine 写 map，得加
sync.RWMutex或改用sync.Map
何时该坚持用接口而不是函数类型
函数类型不是万能的。当策略需要携带状态且该状态在多次调用间需保持一致时，接口更稳妥。
- 比如“阶梯折扣”策略：首次调用后要记录已累计消费额，下次调用要基于历史值计算——函数闭包虽能实现，但状态生命周期难管控
- 策略本身要实现多个方法（如
Validate()+Apply()+Rollback()），单个函数类型撑不住 - 已有大量基于接口的策略生态（如支付 SDK），强行改函数会破坏兼容性
- 团队规范要求显式契约，函数类型太隐晦，新人看不懂
func(int) string到底代表什么语义
真正麻烦的从来不是“怎么写”，而是“什么时候不该这么写”。函数式策略看着简洁，但状态管理和语义表达力弱于接口，别为了省几行代码把边界搞模糊了。
