Go中不该用传统单例模式，因其缺乏类与静态变量语义，且违背显式依赖传递原则；应使用sync.Once控制初始化，或通过New函数实现可测试、可注入的实例创建。
为什么 Go 里不该用传统单例模式
Go 没有类、没有构造函数、也没有“静态变量”的语义，所谓“传统单例”（比如 Java 里的 private static instance）在 Go 里既难写又容易误用。更关键的是，Go 的惯用法天然倾向“显式依赖传递”，硬塞一个全局可访问的单例实例，反而会让测试变难、并发行为不可控、初始化顺序成谜。
真正需要的不是“单例模式”，而是：一个**线程安全、只初始化一次、能被干净注入或复用**的对象。Go 标准库早提供了现成解法。
sync.Once 是最轻量可靠的初始化控制
几乎所有需要“只执行一次”的场景，sync.Once 都是首选——它比手写 if init == nil + sync.Mutex 更简洁，也比原子操作更易读，且能正确处理 panic 后的恢复逻辑。
常见错误是把它和全局变量耦合太紧，或者忘记把初始化逻辑封装进闭包：
- ✅ 正确：用
sync.Once控制初始化，对象本身是包级变量（导出或非导出按需） - ❌ 错误：在
init()函数里初始化，导致无法 mock、无法延迟加载、无法控制依赖顺序 - ❌ 错误：每次调用都 new 一个
sync.Once实例，完全失去“once”意义
示例（带连接池的 HTTP 客户端）：
var (
httpClient *http.Client
once sync.Once
)
<p>func GetHTTPClient() <em>http.Client {
once.Do(func() {
httpClient = &http.Client{
Timeout: 30 </em> time.Second,
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
},
}
})
return httpClient
}如果要支持配置或依赖注入，别用全局变量
当单例需要接收参数（比如数据库 DSN、重试策略、logger 实例），强行塞进包级变量会破坏可测试性。这时候应该把初始化逻辑抽成函数，由上层决定何时、如何构建：
- 导出一个
NewService(...)函数，返回结构体指针 - 用私有字段缓存依赖，不暴露内部状态
- 避免在函数内直接赋值给包级变量；若必须共享，让调用方自己管理生命周期
例如：
type Cache struct {
store map[string]string
mu sync.RWMutex
}
<p>func NewCache(logger <em>zap.Logger) </em>Cache {
return &Cache{
store: make(map[string]string),
// logger 可用于 debug 日志，但不存为全局
}
}这样测试时可以直接传入 nil 或 mock logger，生产代码则统一在 main() 初始化后注入。
注意 init() 和包加载顺序的隐式依赖
很多人图省事，在 init() 里初始化单例，结果遇到依赖的包还没初始化完，或者测试时因包导入顺序不同导致行为不一致。Go 的 init() 执行顺序是确定的，但跨包依赖链一旦复杂就极易踩坑。
尤其要注意：
- 环境变量、配置文件读取失败时，
init()panic 会导致整个程序启动失败，且无明确错误上下文 - 第三方 SDK（如 AWS SDK、gRPC Client）的初始化可能涉及网络或证书加载，放在
init()里会让单元测试无法跳过 - 多个
init()函数之间没有执行优先级声明，靠 import 顺序隐式控制极不健壮
结论很实在：除非是纯内存、无副作用、无依赖的常量初始化（比如预计算的哈希表），否则一律避开 init()。
真正难的从来不是“怎么写单例”，而是想清楚这个实例到底该谁负责创建、什么时候创建、能不能替换、出错时怎么降级——这些设计决策，比 sync.Once 多敲两行代码重要得多。
