go单例靠sync.Once实现线程安全、延迟初始化的全局唯一实例，避免包级变量早初始化缺陷；不支持传参构造，需用选项模式或依赖注入；测试时应可替换实例以隔离状态。
Go 语言里没有“类”和“构造函数”，所谓单例不是靠语法限制，而是靠包级变量 + 同步控制来保证全局唯一实例。直接暴露一个 GetInstance() 函数是最常见、最安全的做法。
用 sync.Once 保证初始化只执行一次
这是 Go 单例最主流的实现方式。它天然线程安全，且延迟初始化（第一次调用才创建），避免包初始化阶段的副作用或依赖未就绪问题。
常见错误是手动加锁做双重检查（double-Check Locking），在 Go 中完全没必要，反而容易出错——sync.Once 就是为此设计的。
-
sync.Once内部已处理内存可见性与竞态，无需额外atomic或mutex - 初始化函数（
once.Do()里传入的）只会被执行一次，哪怕多个 goroutine 同时调用GetInstance() - 如果初始化过程 panic，后续调用仍会 panic；需确保初始化逻辑健壮
var ( instance *DBClient once sync.Once ) func GetInstance() *DBClient { once.Do(func() { instance = &DBClient{conn: connectToDB()} }) return instance }为什么不用包级变量直接初始化？
像 var instance = &DBClient{...} 这样写看似简单，但隐患明显：
立即学习“go语言免费学习笔记（深入）”；
- 包初始化阶段就执行，无法按需加载，可能触发过早的资源分配或外部依赖（如数据库连接、配置读取失败）
- 若初始化逻辑含 panic 或 Error，整个包加载失败，且错误堆栈难以定位
- 无法注入依赖（比如测试时想 mock DB 连接），丧失可测试性
- 某些场景下（如 CLI 工具中多数命令不涉及 DB），属于典型浪费
带参数的单例怎么处理？
Go 的单例函数本身不支持传参（否则无法保证“单”）。真有配置差异需求，常见做法是：
- 把配置作为结构体字段，在
GetInstance()初始化前通过另一个函数设置（如SetConfig(cfg Config)），但要注意并发安全 - 更推荐：用函数选项模式（Functional Options）封装初始化逻辑，把配置收进闭包，再交给
sync.Once - 极端情况（如多套隔离环境），放弃“全局单例”，改用依赖注入容器（如
uber/fx）或显式传递实例
硬要在 GetInstance(url String) 里传参，结果就是每个不同参数都生成一个实例——那已经不是单例，而是对象池或工厂了。
测试时如何替换单例实例？
Go 单例最难测的地方在于：它默认绑死全局状态。解决方法很朴素：
- 把包级
instance变量设为可导出（如Instance），测试中直接赋值覆盖（注意加init()或TestMain恢复） - 更稳妥：定义接口 + 实例变量 + 设置函数，例如
func SetClient(c DBClient)，测试中注入 mock - 避免在
init()里初始化单例，否则测试无法干预时机
真正麻烦的不是实现，而是忘记单例会污染测试上下文——两个测试用同一个实例，其中一个改了内部状态（比如缓存、连接池计数），另一个就可能意外失败。