该用设计模式当且仅当：同一逻辑在三个以上上下文重复出现、不抽象会导致多处修改、新人能通过接口名快速理解职责；否则属过度设计。
什么时候该用设计模式，而不是直接写逻辑
Go 语言没有接口继承、没有泛型（旧版）、没有构造函数重载，这些特性天然抑制了传统面向对象中常见的模式滥用。实际项目里，if err != nil 后直接 return 比套一层 Strategy 更常见也更合理。是否引入模式，关键看三点：
- 同一段逻辑在三个以上不同上下文中重复出现，且变化点明确（比如支付方式：alipay、wxpay、stripe）
- 不加抽象会导致后续修改必须改多处（比如日志输出从 console 切到 Kafka，涉及 8 个 handler）
- 团队新人接手时，能通过接口名 + 方法签名快速理解职责边界（如
type Notifier interface { Send(context.Context, string) error }）
反之，如果只是“未来可能扩展”，但当前只有 1 种实现，硬加 Factory 或 AbstractFactory 就是过度设计。
Go 里最常被误用的三个模式及其替代方案
1. 不要为单例写 Singleton 结构体
Go 的包级变量 + sync.Once 足够安全，且更轻量：
var (
once sync.Once
db *sql.DB
)
func GetDB() *sql.DB {
once.Do(func() {
db = sql.Open("mysql", "user:pass@/dbname")
})
return db
}
2. 避免提前抽象 Template Method
Go 没有抽象方法语法，靠组合+函数字段模拟，容易让调用方困惑。不如直接暴露 Process(ctx context.Context, input any, fn func(any) error) 这类高阶函数。
3. Observer 模式慎用 channel 实现
多个 goroutine 往同一个 chan 发送事件，若消费者阻塞或未及时读取，会卡住整个流程。更稳妥的是用 pubsub 库（如 nats.go）或简单回调切片：
type EventBroker struct {
handlers []func(Event)
}
func (b *EventBroker) Subscribe(h func(Event)) {
b.handlers = append(b.handlers, h)
}
func (b *EventBroker) Publish(e Event) {
for _, h := range b.hand
lers {
h(e) // 同步调用，可控、易测
}
}
接口定义的粒度与命名陷阱
Go 接口应小而专注，遵循 io.Reader / io.Writer 级别的简洁性。常见错误包括：
- 接口方法超过 3 个，尤其混入生命周期控制（
Init()/Close()）和业务逻辑（DoWork()） - 名字带 “Manager”、“Handler”、“Processor” —— 这类词几乎总意味着职责不清
- 导出接口却只在本包内实现，外部无法 mock，单元测试被迫走真实依赖
推荐做法：type Cache interface { Get(key string) ([]byte, error); Set(key string, val []byte) error }。如果某处需要缓存+持久化+通知，就组合多个接口，而非定义一个大而全的 DataStore。
测试驱动设计比模式驱动设计更适配 Go
很多“模式需求”其实在写测试时才真正浮现。例如：
- 想 mock 数据库？先写测试，发现
*sql.DB太难 fake，再提取Querier接口 - 想隔离 HTTP client？等测试里遇到超时或重试逻辑难控制，再封装
HTTPClient接口 - 想统一错误处理？等多个 handler 都写了重复的
http.Error(w, err.Error(), http.StatusInternalServerError)，再抽象ErrorResponse工具函数
过早设计模式，反而会让测试变重——你得 mock 整个策略树，而不是一个函数。Go 的简洁性在于：先让代码跑起来，再让代码可测，最后让代码可扩。
真正容易被忽略的，是接口的演化成本。一旦导出一个接口，所有实现都得跟着改。宁可多导出几个小接口，也不要等“感觉差不多了”才合并成一个大接口。
