Go反对教条套用设计模式，主张用包变量、函数、接口和组合等原语直击问题；NewXXX()函数、函数选项等惯用法比工厂接口、装饰器结构体更轻量、清晰、易维护。
Go 不反对设计模式，但反对过早、生硬、教条地套用设计模式——这不是语言能力不足，而是对 Go 的工程哲学理解偏差。
Go 的简洁不是功能少，而是把“默认路径”设计得足够直白：接口隐式实现、函数是一等公民、包级封装、组合优于继承。当这些原语就能干净解决问题时，硬加 Factory、Observer、Builder 反而增加认知负担和维护成本。
什么时候该用单例？什么时候该直接用包变量？
很多新手看到“全局唯一”就立刻写 sync.Once + GetInstance()，但 Go 中更自然的写法往往是：
- 配置对象：直接定义
var Config = &config{...}，在init()里初始化，够用且无竞态 - 日志器：
log.Default()或zap.L()已是单例语义，无需再包一层 - 数据库连接池：
sql.Open()返回的*sql.DB本身就是线程安全的共享句柄，它内部已做连接复用，你再套个单例纯属冗余
只有当你需要「延迟初始化 + 多协程首次竞争安全」时，sync.Once 才真正必要。否则，包级变量 + init() 更轻、更易测试、更符合 Go 的惯用法。
立即学习“go语言免费学习笔记（深入）”；
工厂函数 vs 工厂接口：为什么 Go 常见的是 NewXXX() 而不是 Creator 接口？
Go 的工厂，90% 是一个普通函数，比如 NewHTTPClient()、NewRouter()、NewStore()。它不返回接口，也不依赖抽象基类——因为 Go 的接口是「使用方定义」的，不是「实现方继承」的。
- 如果下游只用到
io.Reader，你就返回bytes.NewReader()，不用管它是不是某个ReaderFactory的产物 - 如果要支持多后端（如内存/Redis/PostgreSQL），优先考虑通过参数或选项控制行为，而不是拆出
MemoryStoreFactory和RedisStoreFactory - 真正需要接口抽象的场景极少，比如插件系统或高度可替换的驱动层（如
database/sql/driver），这时才值得定义工厂接口
滥用工厂接口会带来不必要的间接层：调用链变长、mock 成本升高、IDE 跳转迷失。而 NewXXX() 函数一眼可知返回什么、怎么配、是否可定制。
装饰器和选项模式：为什么 func(*T) *T 比 type Decorator struct{...} 更 Go？
HTTP 中间件、客户端配置、SQL 构建器……这些本该灵活组合的场景，在 Go 里最自然的表达是高阶函数或函数选项（Functional Options）：
srv := NewServer(
WithPort(8080),
WithTimeout(30*time.Second),
WithLogger(zap.L()),
)
而不是：
srv := &Server{}
srv = &PortDecorator{Decorated: srv, Port: 8080}
srv = &TimeoutDecorator{Decorated: srv, Timeout: 30*time.Second}
- 前者零分配、无嵌套结构、类型推导清晰；后者需定义一堆装饰器类型，还容易陷入“装饰器套装饰器”的可读性黑洞
- 函数选项天然支持任意顺序、可选省略、可复用（
ProdOptions()一键导入），而结构体装饰器一旦嵌套深了，就很难调试和单元测试 -
标准库如
http.Server、grpc.Dial、sql.OpenDB全部采用函数选项，这是经过大规模验证的 Go 风格
Go 的“少用设计模式”，本质是拒绝为模式而模式。它鼓励你先写清楚需求，再用最短路径抵达——往往那个路径就是包变量、函数、接口、组合，而不是先画类图、再套 UML。最容易被忽略的一点是：Go 项目里最难维护的，从来不是没用设计模式的地方，而是用了设计模式却没解决实际问题、反而遮蔽了数据流向和控制流的地方。
