单例唯一性验证需确保instance地址始终一致且初始化函数仅执行一次，应通过≥1000 goroutine并发调用GetInstance配合sync.WaitGroup同步后断言，并检查once.Do内无隐式并发、错误路径下instance与err一致性及对象内部状态线程安全。
用 sync.WaitGroup + 多 goroutine 跑满初始化逻辑
单例唯一性不是靠“看起来没报错”来验证的，而是看 instance 地址是否始终一致、初始化函数是否真只执行一次。最直接的办法是：启动大量 goroutine 并发调用 GetInstance()，用 sync.WaitGroup 确保全部完成后再断言。
- 在初始化闭包里加计数器（如
initCount++）或打日志（fmt.Println("init called")），观察输出是否仅一行 - 用
fmt.Printf("%p", instance)打印地址，所有 goroutine 返回的指针必须完全相同 - 避免在测试中用
time.Sleep等待——它不可靠，且掩盖竞态；必须用WaitGroup或chan同步 - 并发数建议 ≥ 1000，低并发（如 10）很可能漏掉问题，尤其在 CI 环境下
检查 once.Do 是否真的阻止了重复初始化
sync.Once 的语义是“函数体只执行一次”，但它不保证你写的初始化逻辑里没有隐式并发漏洞。常见翻车点是：在 once.Do 闭包内又开了 goroutine 去构造对象，导致外部看到 instance 已赋值，但内部字段还没写完。
- 不要在
once.Do(func())里起 goroutine 初始化成员（比如go loadCache()），这会让instance提前暴露为非 nil，但状态不完整 - 如果初始化过程必须异步（如预热大缓存），应把整个异步流程封装进一个同步阻塞函数里，再传给
Do - 测试时可加
runtime.Gosched()在关键赋值前后，人为放大调度间隙，更容易触发读到半初始化对象的问题
验证错误路径下 instance 和 err 的一致性
带错误返回的单例（比如数据库连接失败）最容易出错：多个 goroutine 可能同时看到 instance == nil，然后都去执行初始化，结果一个成功赋值 instance，另一个赋值 err，最终调用方拿到 nil 实例却查不到 err。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须声明
var instance *DB, err error（注意err是包级变量，不是闭包内局部变量） - 闭包里要写成
instance, err = newDB(dsn)，而不是分开两行赋值 - 测试时模拟失败（如传空
dsn），并发调用后检查：所有返回的instance都是nil，且err != nil—— 且只被赋值一次 - 别用
if err != nil { panic(...) }替代显式错误传播，那会让测试无法捕获失败路径
别忘了单例对象自身的线程安全
sync.Once 只管“创建一次”，不管“用的时候安不安全”。如果你的单例结构体里有可变字段（比如计数器、map、切片），并发读写照样 panic 或数据错乱。
立即学习“go语言免费学习笔记（深入）”；
- 测试不能只盯
GetInstance()，还得对返回的实例做并发读写操作（如inst.IncCounter()被 100 个 goroutine 同时调用） - 如果单例内部有状态，必须自己加锁（
sync.RWMutex）或用原子操作（atomic.AddInt64） - 导出的方法命名要体现是否线程安全，比如
GetCount()是只读，IncCount()是写操作，文档或注释里得写清楚
