为什么不能直接用包级变量做单例？
包级变量看似最简单，但容易在测试、热重载或模块化场景下失控。比如 var db *sql.DB 在 init 函数里初始化后，整个进程生命周期内无法替换——单元测试想 mock 就只能靠全局替换指针，极易污染其他测试用例。
更麻烦的是：多个 import 路径（如 ./pkg/db 和 ../pkg/db）可能触发多次 init，导致重复初始化或竞态，而 Go 不保证包初始化顺序，依赖链一深就出问题。
实操建议：
- 避免裸包级变量 +
init()组合，除非是纯常量或无副作用的只读结构体 - 若必须用包级变量，确保其初始化逻辑幂等，且不依赖其他未确定初始化状态的包
- 优先把“单例创建”收口到一个函数里，比如
NewDB()，由调用方显式控制生命周期起点
Init 函数里初始化单例的风险在哪？
init() 是隐式执行的，你没法控制它什么时候跑、是否已准备好依赖项。常见错误现象是：在 init() 里调用 os.Getenv("DB_URL")，结果环境变量还没被主程序加载；或者依赖另一个包的 Config 变量，但它还没初始化完毕，导致 panic 或空指针。
立即学习“go语言免费学习笔记（深入）”；
性能上没明显损耗，但可测性几乎归零——你没法在测试中跳过或重放 init()。兼容性方面，Go 1.21+ 对 init 顺序做了更严格约束，但跨包依赖仍不可靠。
实操建议：
- 把
init()降级为“仅注册”，比如registerDefaultDBCreator()，真初始化留到首次调用时懒加载 - 如果非要用
init()，只做最轻量的事：设置默认值、注册钩子、初始化 sync.Once 实例，别碰 I/O 或外部依赖 - 检查
go list -deps . | grep yourpkg，确认该包不会被间接 import 多次
如何用 sync.Once 实现线程安全的懒加载单例？
这是目前最稳妥的做法：单例对象只在第一次被需要时构造，且保证并发安全。比包级变量可控，比 init 更易测试，也避免了提前初始化失败的问题。
关键点在于把 “创建逻辑” 和 “暴露接口” 分开。不要让 GetDB() 直接返回包级变量，而是封装一层控制流。
实操建议：
- 声明私有变量和 once 控制器：
var (dbOnce sync.Once; dbInstance *sql.DB) - 暴露函数时用指针接收：
func GetDB() *sql.DB { dbOnce.Do(func() { dbInstance = NewDBFromEnv() }); return dbInstance } - 如果单例需要参数（比如不同环境配置），就别用
sync.Once做全局单例，改用依赖注入容器或工厂函数 - 注意：一旦
Do()执行失败（panic），sync.Once会永久标记为“已完成”，后续调用不再尝试，所以初始化函数里要自己 recover 错误并记录日志
什么时候该放弃单例，转用显式依赖注入？
当你的服务开始需要多实例（比如测试用内存 DB、生产用 PostgreSQL）、或模块之间存在循环依赖、或你想做运行时切换（如灰度流量打到不同 DB 实例），硬编码单例就成了绊脚石。
典型信号是：你在写测试时频繁用 reflect.ValueOf(&db).Elem().Set(...) 强行覆盖包级变量，或者为了绕过单例加了一堆 if testing.Testing() 分支。
实操建议：
- 把单例从“全局可访问”变成“构造时传入”，比如
http.NewServer(handler, &ServerConfig{DB: db}) - 用结构体字段存依赖，而不是包级变量：
type UserService struct { db *sql.DB }，这样每个实例可独立配置 - 如果不想手动传，可用 fx、wire 等 DI 工具，但前提是团队接受额外抽象层——小项目反而增加理解成本
真正难的不是写一个 sync.Once，而是判断这个单例到底该活在哪个作用域里：是整个进程、某个 HTTP handler 生命周期、还是每次 RPC 请求？边界模糊时，先选窄作用域，后面再放宽总比反过来容易。
