Go中Singleton无需加锁，因包级变量初始化天然串行；sync.Once或Mutex多属过度设计，真正需线程安全的是运行时动态创建复用的实例。
为什么你的 Singleton 在 Go 里其实不需要加锁
Go 的包级变量初始化天然串行，sync.Once 或 sync.Mutex 包裹的单例初始化多数是过度设计。真正需要线程安全的是「运行时动态创建+复用」的实例（比如按 key 缓存不同数据库连接），而不是包初始化阶段就该定下来的全局对象。
常见错误现象：GetInstance() 方法里反复调用 once.Do()，但实际只在 init() 里初始化一次就够了；或者把整个结构体方法都加锁，导致并发吞吐骤降。
- 优先用包级变量 +
var instance = &MyService{...}直接声明 - 若需延迟初始化（如依赖配置加载后才构建），用
sync.Once，但仅包裹初始化逻辑，不包裹后续方法调用 - 避免在
GetInstance()返回值上做深拷贝或加锁——返回指针即可，线程安全由使用者保障
Factory 模式在 Go 中常被写成「if-else 垃圾场」
Go 没有构造函数重载，也没有泛型约束（旧版），开发者容易写出大量硬编码分支来选实现类型，比如 switch typeStr { case "mysql": return &MysqlRepo{} ... }。这类代码难以测试、无法静态检查、新增类型必须改工厂。
更自然的替代方式是注册表 + 接口组合：
立即学习“go语言免费学习笔记（深入）”；
var repoFactories = make(map[string]func() Repository)
func RegisterRepo(name string, f func() Repository) {
repoFactories[name] = f
}
func NewRepository(name string) Repository {
if f, ok := repoFactories[name]; ok {
return f()
}
panic("unknown repo: " + name)
}
- 注册放在
init()函数中，各模块自举，主程序无需感知所有实现 - 测试时可临时
RegisterRepo("mock", func() Repository {...})替换 - 避免在工厂里做资源初始化（如打开 DB 连接）——工厂只负责构造，启动逻辑放
Start()方法里
接口定义过大导致 Adapter 和 Decorator 变成补丁工具
当一个接口包含 8 个方法，而实际只用其中 2 个时，为满足接口不得不实现空方法或包装器，这就是接口污染。Go 的接口应遵循「小而专」：按调用方视角定义，不是按实现方能力堆砌。
例如：type Reader interface { Read(p []byte) (n int, err error); Close() error; Seek(...) } —— 如果只是 HTTP handler 读请求体，Seek 就不该出现在这里。
- 优先定义窄接口：
type DataReader interface { Read() ([]byte, error) } - 多个小接口可组合：
type ReadCloser interface { DataReader; io.Closer } - 不要为了「统一抽象」强行让不相关的类型实现同一接口（比如让
*bytes.Buffer和*sql.DB都实现Storer）
泛型出现后，Template Method 和 Strategy 大量退化为冗余封装
Go 1.18+ 泛型支持函数参数、约束类型和内联策略，很多过去靠继承/接口+回调实现的模式，现在一行函数调用就能解决。典型滥用：为每个算法写一个 Sorter 接口实现，再传给 Processor.Process()。
更直接的方式是接收函数：
func Process[T any](data []T, compare func(a, b T) bool) []T {
sort.Slice(data, func(i, j int) bool {
return compare(data[i], data[j])
})
return data
}
- 策略即函数，无需额外结构体和方法绑定
- 编译期单态化，无接口动态调用开销
- 只有当策略需要携带状态（如带缓存的比较器）时，才考虑封装为 struct + 方法
模式本身没有错，错在忽略 Go 的语法特性去套用其他语言的惯性解法。最危险的滥用不是写错，而是写得“太像 Java”，结果失去 Go 的简洁与性能优势。
