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”，所有中间件（日志、鉴权、限流）都该遵循这个签名。
UQ云商B2B2C系统
下载
UQCMS云商是一款B2B2C电子商务软件 ，非常适合初创的创业者，个人及中小型企业。程序采用PHP+MYSQL,模板采用smarty模板，二次开发，简单方便，无需学习其他框架就可以自行模板设计。永久免费使用，操作简单，安全稳定。支持PC+WAP+微信三种浏览方式，支持微信公众号。
立即学习“go语言免费学习笔记（深入）”；
- 不要试图用嵌入结构体 + 方法重写模拟 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 就能搞定，强行套模式只会让代码更难懂。
