Go单例唯一可靠实现是sync.Once配合包级指针变量，因其线程安全、延迟初始化且支持错误返回；禁用if-nil判断、init函数及局部once声明。
Go 语言没有构造函数，所谓“利用单例模式构造函数”本身是个误导性说法——你没法靠私有构造函数阻止实例化，必须用别的机制来控制唯一性。
为什么 Go 里不存在传统意义上的构造函数
Go 没有类、没有访问修饰符（private / public），结构体字段和方法的可见性只由首字母大小写决定。你无法把 NewConfig 函数设为“外部不可见”，也无法禁止别人直接写 Config{} 创建副本。所以，单例的约束不是靠语法锁死，而是靠约定 + 初始化逻辑 + 并发控制三者共同维持。
常见错误是以为只要把 Config 结构体首字母小写、把 NewConfig 设为小写就能防住外部创建——其实只要包内有导出字段，外部仍可通过字面量或反射绕过。
- 结构体字段必须全小写（如
data map[string]interface{}）才能真正“私有” -
NewConfig必须是导出函数（首字母大写），否则其他包根本调不到 - 真正起作用的是初始化时机和并发保护，不是函数名是否导出
sync.Once 是唯一靠谱的初始化守门员
不用 sync.Once，只靠 if instance == nil 判断，在高并发下必然产生多个实例。哪怕只是两个 goroutine 同时进入判断，都可能各自执行初始化并覆盖对方。
立即学习“go语言免费学习笔记（深入）”；
sync.Once.Do 内部用原子操作 + 互斥锁双重保障，确保传入的函数**绝对只执行一次**，且后续所有调用立即返回，不阻塞也不重复初始化。
- 必须把实例变量声明为指针类型（如
*Config），否则赋值是值拷贝，外部拿到的是副本 - 初始化函数里避免耗时操作（比如读取大配置文件、连接数据库），否则所有等待的 goroutine 都卡住
- 不要在
init()函数里做单例初始化——它无法返回错误，也无法按需延迟加载
跨模块共享配置时最容易踩的坑
配置冲突往往不是因为实例不唯一，而是因为多个模块各自 new 了一个 Config 实例，或误用了未初始化的全局变量。
典型现象：fmt.Printf("%p", GetConfig()) 在不同包里打印出不同地址；或者修改 A 模块里的配置项，B 模块读不到更新。
- 确保所有模块都 import 同一个包路径（比如
github.com/yourorg/config），而不是本地 copy 一份代码 - 不要在多个包里各自定义
var config *Config—— 这等于造了多个“单例” - 如果配置需要热重载，单例本身不能 reload，得在单例内部封装
Reload()方法，并保证线程安全 - 测试时用
go test -race跑一遍，能暴露大部分竞态问题
真正难的不是写出一个“看起来像单例”的代码，而是让所有协程、所有包、所有测试用例都通过同一个入口拿实例——这要求包设计清晰、导入路径统一、初始化逻辑无副作用。
