Golang策略模式使用与实战示例

本文深入探讨了Go语言中策略模式的惯用实践，强调摒弃Java/C#式接口继承的思维定式，优先采用轻量简洁的函数类型（如`func(string, map[string]interface{}) string`）定义策略，显著降低调用开销、提升可测试性与可组合性；仅当策略需维护状态（如限流器中的时间窗口或缓存）时，才借助结构体封装，真正实现“按需抽象、解耦算法、零侵入上下文”的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)
    }
<pre class="brush:php;toolbar:false;">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
}
<p>func (l *Logger) Log(msg string, fields map[string]interface{}) {
fmt.Println(l.formatter(msg, fields))
}</p><p>// 使用
logger := &Logger{formatter: JSONFormatter}
logger.Log("user login", map[string]interface{}{"uid": 123, "ip": "192.168.1.1"})</p>

当策略需要状态时：用结构体封装

比如一个限流策略，要记录最近请求时间戳。这时函数类型不够用，得用结构体：

type RateLimiter struct {
    maxReqPerSec float64
    window       time.Duration
    lastRequests []time.Time
    mu           sync.RWMutex
}
<p>func (r *RateLimiter) Allow() bool {
r.mu.Lock()
defer r.mu.Unlock()</p><pre class="brush:php;toolbar:false;">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
}
<p>func (p *PaymentService) Charge(amount float64) error {
if !p.limiter.Allow() {
return errors.New("rate limit exceeded")
}
// ... 执行支付
return nil
}</p>

容易踩的坑：别在策略里做阻塞或全局状态操作

策略的核心职责是“计算”或“决策”，不是“执行副作用”。以下写法很危险：

• 在 LogFormatter 函数里直接调用 os.WriteFile —— 这已超出格式化职责，应由 logger 调用方统一处理 I/O
• 在 RateLimiter.Allow() 里启动 goroutine 清理旧数据 —— 状态管理应同步、确定，异步清理会引发竞态或内存泄漏
• 把策略实例存在全局变量里（如 var DefaultFormatter LogFormatter），导致无法按场景切换，也难以 mock 测试

策略对象的生命期应由使用者控制，它的方法必须是无副作用的纯计算，或者明确标注并发安全（如加锁）。Go 的策略模式真正难的不是怎么写，而是想清楚：这个逻辑到底该不该独立成策略？还是就该写成一个普通函数？

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Golang策略模式使用与实战示例》文章吧，也可关注golang学习网公众号了解相关技术文章。