Go中应放弃Abstract Factory、Builder、Decorator、Observer等模式，因其与Go隐式接口、组合优先特性冲突；推荐Option、Adapter、Strategy等贴合Go习惯的模式。
Go 语言项目里不是“要不要用设计模式”，而是“哪些设计模式真能用、哪些一用就翻车”。
Go 里哪些设计模式基本可以放弃
Go 没有类继承、没有泛型（旧版）、接口是隐式实现，导致很多面向对象语言里常见的模式在 Go 中既难写又难维护。
-
Abstract Factory和Builder：Go 偏好直接返回结构体或使用函数选项（functional options），硬套工厂类只会让初始化代码更绕 -
Decorator（装饰器）：Go 的接口组合和嵌入（embedding）天然支持行为叠加，再套一层decorator类型反而增加间接性 -
Observer（观察者）：channel + goroutine 组合通常比注册/通知回调更清晰；手动维护 observer 列表容易漏掉取消逻辑，引发 goroutine 泄漏
真正适合 Go 的设计模式（带典型场景）
这些模式贴合 Go 的语法习惯和工程直觉，用对了能显著降低理解成本。
-
Option Pattern：用于构造函数参数扩展，比如http.Client或自定义的NewServer(...ServerOption)。比可变参数或结构体字段赋值更安全、更易扩展 -
Adapter：把第三方库接口适配成你内部定义的interface{}，例如把*sql.DB封装成DataStore接口，方便 mock 和替换 -
Strategy：用函数类型或接口实现算法切换，比如日志输出策略（func(msg string) error）、重试策略（type RetryPolicy interface { Next(...) time.Duration }）
type PaymentProcessor interface {
Process(amount float64) error
}
type StripeProcessor struct{}
func (s StripeProcessor) Process(amount float64) error {
// 调用 stripe SDK
return nil
}
type MockProcessor struct{}
func (m MockProcessor) Process(amount float64) error {
return nil
}
// 测试时直接传 MockProcessor，无需改业务逻辑
func Charge(p PaymentProcessor, amount float64) error {
return p.Process(amount)
}
容易踩坑的“伪模式”实践
有些写法看起来像模式，实则是 Go 工程中高频出问题的反模式。
易优cms汽车车辆租赁源码1.7.2
下载
由于疫情等原因大家都开始习惯了通过互联网上租车服务的信息多方面，且获取方式简便，不管是婚庆用车、旅游租车、还是短租等租车业务。越来越多租车企业都开始主动把租车业务推向给潜在需求客户，所以如何设计一个租车网站，以便在同行中脱颖而出就重要了，易优cms针对租车行业市场需求、目标客户、盈利模式等，进行策划、设计、制作，建设一个符合用户与搜索引擎需求的租车网站源码。 网站首页
立即学习“go语言免费学习笔记（深入）”；
- 过度抽象
Repository层：为每个实体写UserRepo、OrderRepo接口，但实际只有一种实现（如 PostgreSQL），接口纯属冗余，还阻碍 SQL 优化 - 滥用
Context传递非生命周期相关数据：比如把用户 ID、配置项塞进context.WithValue，导致调用链难以追踪、类型不安全 - 把
sync.Once当单例模式用：它只保证初始化一次，不控制实例生命周期；多个包并发调用init()风格函数仍可能产生多个实例
Go 的简洁性来自克制，而不是填满教科书里的模式列表。真正该花时间的，是定义清晰的接口边界、设计可测试的数据流、以及让错误处理路径显式可见——这些比记住某个模式的名字重要得多。
