Golang实战中最常用的几种设计模式

Go高频实用设计模式仅五个：单例（必用sync.Once）、工厂（NewXXX构造函数）、装饰器（HTTP中间件式闭包）、观察者（多异构事件响应）、模板方法（固定流程+可变步骤）。

Go 语言实战中真正高频、开箱即用、不造轮子也不过度设计的设计模式，就那么几个：单例、工厂（含简单工厂和工厂方法）、装饰器、观察者、模板方法。其他如抽象工厂、建造者、原型等，除非业务极度复杂或有明确框架约束，否则极少在日常服务开发中主动引入。

sync.Once 是单例模式的唯一正解，别手写双重检查

Go 没有类和构造函数，所谓“单例”本质是全局变量 + 线程安全初始化。自己用 mutex 加锁做双重检查不仅冗余，还容易出错（比如忘记锁读）。

• 必须用 sync.Once —— 它底层用原子操作+互斥锁混合实现，性能好且语义清晰
• 初始化逻辑必须放在 once.Do() 的闭包里，不能提前赋值（否则可能被并发读到零值）
• 返回指针类型（*Config），避免结构体拷贝破坏单例语义

type Config struct {
    Port int
    Env  string
}
var (
    instance *Config
    once     sync.Once
)
func GetConfig() *Config {
    once.Do(func() {
        // 这里可以加载文件、解析环境变量、校验字段
        instance = &Config{Port: 8080, Env: os.Getenv("ENV")}
    })
    return instance
}

工厂模式不是“模式”，而是 Go 的惯用法：func NewXXX(...)

Go 不强调继承和抽象类，所以“工厂方法模式”在 Go 中退化为一组命名规范的构造函数：用 NewDB、NewLogger、NewCache 封装创建逻辑，配合接口返回，就是最实用的工厂。

• 不要为了“模式”而抽象出 Creator 接口——除非你真要支持运行时插拔多种工厂实现
• 参数尽量用结构体选项（option pattern）替代长参数列表，利于扩展
• 错误必须显式返回，不能 panic（NewDatabase("oracle") 报错应返回 error，而非 panic）

type DB interface {
    Query(string) string
}

func NewDB(driver string, opts ...DBOption) (DB, error) {
    o := defaultDBOptions()
    for _, opt := range opts {
        opt(o)
    }
    switch driver {
    case "mysql":
        return &MySQL{timeout: o.timeout}, nil
    case "pg":
        return &PgSQL{poolSize: o.poolSize}, nil
    default:
        return nil, fmt.Errorf("unsupported driver: %s", driver)
    }
}

装饰器模式靠闭包和组合，不是继承：HTTP 中间件就是典型

Go 没有装饰器语法，但 http.HandlerFunc 链式调用天然适配装饰器思想。核心是“接收 handler，返回新 handler”，所有中间件（日志、鉴权、限流）都该遵循这个签名。

• 不要试图用嵌入结构体 + 方法重写模拟 OOP 装饰器——太重，且破坏 handler 的函数本质
• 中间件顺序很重要：认证应在日志之后、业务之前；恢复 panic 应在最外层
• 避免在装饰器里修改原始 http.ResponseWriter，要用 ResponseWriter 包装器（如 responsewriter.Wrap）捕获状态码

func WithAuth(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        token := r.Header.Get("Authorization")
        if !isValidToken(token) {
            http.Error(w, "unauthorized", http.StatusUnauthorized)
            return
        }
        next(w, r) // 继续调用下游
    }
}

func main() {
    http.HandleFunc("/api/user", WithAuth(WithLogging(userHandler)))
}

观察者和模板方法，只在状态流转/流程固定时才值得用

这两个模式容易被误用成“设计感陷阱”。它们真正的适用信号很明确：

• 观察者：当一个事件发生后，**多个异构行为必须响应**，且这些行为生命周期独立（如订单创建后发短信、推消息、更新积分），且未来可能增删响应者
• 模板方法：当一组操作**步骤固定、顺序不可变，仅个别步骤逻辑差异大**（如支付流程：校验→扣款→发通知→记账，只有“扣款”对接不同渠道）
• 否则直接用回调函数或 switch 分支更轻量——Go 不需要为“可扩展性”提前抽象

// 模板方法示例：统一支付骨架
type PaymentProcessor interface {
    Validate() error
    Charge() error
    Notify() error
    Log() // 模板方法内固定调用
}

func (p *AlipayProcessor) Execute() error {
    if err := p.Validate(); err != nil {
        return err
    }
    if err := p.Charge(); err != nil {
        return err
    }
    p.Notify() // 固定流程
    p.Log()    // 固定流程
    return nil
}

最容易被忽略的一点：Go 的接口极轻，但滥用接口抽象反而增加维护成本。单例、工厂、装饰器之所以常用，是因为它们解决的是 Go 自身机制的短板（无全局状态管理、无构造函数、无 AOP）；而像策略、状态、责任链这些，往往用一个 map[string]func 或 switch 就能搞定，强行套模式只会让代码更难懂。