Go中策略模式优先用函数类型而非接口，仅当需维护状态时才用结构体；核心是解耦算法逻辑，避免冗余抽象与副作用。
Go 语言没有类继承和接口实现的强制约束，策略模式不能照搬 Java/C# 那套写法，但用 interface + 函数值 + 结构体组合，反而更轻量、更符合 Go 的惯用风格。关键不在“模式名称”，而在能否让不同算法逻辑解耦、可替换、不侵入上下文。
为什么 Go 里不用嵌入接口实现类？
常见误区是定义一个 Strategy 接口，再写一堆 ConcreteStrategyA、ConcreteStrategyB 结构体去实现它——这可行，但冗余。Go 更推荐直接把策略定义为函数类型或闭包，除非策略内部需要维护状态（比如带缓存的重试器）。
-
func(string) string比type Strategy interface { Do(string) string }更简洁，调用开销更低 - 如果策略需复用状态（如计数器、连接池），才用结构体 + 方法；否则纯函数更易测试、更易传参
- 接口应只描述行为契约，而非充当“策略容器”——过度抽象反而增加维护成本
用函数类型定义策略：最简实战写法
假设要做日志格式化，支持 JSON、纯文本、带 traceID 三种输出方式。先定义策略类型：
type LogFormatter func(msg string, fields map[string]interface{}) string然后提供具体实现：
var (
JSONFormatter LogFormatter = func(msg string, fields map[string]interface{}) string {
data := map[string]interface{}{"msg": msg}
for k, v := range fields {
data[k] = v
}
b, _ := json.Marshal(data)
return string(b)
}
TextFormatter LogFormatter = func(msg string, fields map[string]interface{}) string {
parts := []string{msg}
for k, v := range fields {
parts = append(parts, fmt.Sprintf("%s=%v", k, v))
}
return strings.Join(parts, " ")
})
使用时直接注入：
type Logger struct {
formatter LogFormatter
}
func (l *Logger) Log(msg string, fields map[string]interface{}) {
fmt.Println(l.formatter(msg, fields))
}
// 使用
logger := &Logger{formatter: JSONFormatter}
logger.Log("user login", map[string]interface{}{"uid": 123, "ip": "192.168.1.1"})
当策略需要状态时：用结构体封装
比如一个限流策略，要记录最近请求时间戳。这时函数类型不够用，得用结构体：
type RateLimiter struct {
maxReqPerSec float64
window time.Duration
lastRequests []time.Time
mu sync.RWMutex
}
func (r *RateLimiter) Allow() bool {
r.mu.Lock()
defer r.mu.Unlock()
now := time.Now()
r.lastRequests = append(r.lastRequests, now)
// 清理过期请求
cutoff := now.Add(-r.window)
i := 0
for i < len(r.lastRequests) && r.lastRequests[i].Before(cutoff) {
i++
}
r.lastRequests = r.lastRequests[i:]
return float64(len(r.lastRequests)) <= r.maxReqPerSec*r.window.Seconds()}
此时策略不是“一个函数”，而是一个具备生命周期的对象。你可以把它作为字段注入到业务结构体中：
type PaymentService struct {
limiter *RateLimiter
}
func (p *PaymentService) Charge(amount float64) error {
if !p.limiter.Allow() {
return errors.New("rate limit exceeded")
}
// ... 执行支付
return nil
}
容易踩的坑：别在策略里做阻塞或全局状态操作
策略的核心职责是“计算”或“决策”，不是“执行副作用”。以下写法很危险：
- 在
LogFormatte函数里直接调用
r
os.WriteFile—— 这已超出格式化职责，应由 logger 调用方统一处理 I/O - 在
RateLimiter.Allow()里启动 goroutine 清理旧数据 —— 状态管理应同步、确定，异步清理会引发竞态或内存泄漏 - 把策略实例存在全局变量里（如
var DefaultFormatter LogFormatter），导致无法按场景切换，也难以 mock 测试
策略对象的生命期应由使用者控制，它的方法必须是无副作用的纯计算，或者明确标注并发安全（如加锁）。Go 的策略模式真正难的不是怎么写，而是想清楚：这个逻辑到底该不该独立成策略？还是就该写成一个普通函数？
