go单例本质是确保结构体指针变量只被赋值一次且线程安全；饿汉式在包加载时初始化，简单并发安全但不灵活；懒汉式须用sync.once而非手写锁；字段导出取决于是否需外部直接访问；测试应避免重置单例状态，优先测初始化逻辑和依赖注入。
Go 里没有类，所以单例模式不是“确保一个类只有一个实例”，而是“确保一个结构体指针变量只被赋值一次，并线程安全地返回它”——这是所有实现的底层共识，也是你踩坑前必须认清的前提。
饿汉式单例：包加载时就初始化，简单但不灵活
饿汉式本质是利用 Go 包初始化顺序，在 init() 函数或包级变量声明时直接构造实例。它天然并发安全，无锁、无延迟，但缺点也很实在：不管后续用不用，实例都会在程序启动时占内存。
-
var instance *Singleton = &Singleton{Name: "default"}这种写法最直白，但无法做带副作用的初始化（比如读配置、连数据库） - 更稳妥的是用
init()函数：func init() { instance = newSingletonFromConfig() }，可封装复杂初始化逻辑 - 注意：如果初始化过程 panic，整个包导入会失败，错误堆栈可能不易定位
懒汉式单例：首次调用才创建，必须用 sync.Once 而非手写锁
手写双重检查（double-check）加锁看似合理，但在 Go 中极易出错：编译器重排、CPU 指令重排都可能导致未完全初始化的对象被其他 goroutine 看到。Go 标准库的 sync.Once 就是为这事设计的，它内部已处理好内存屏障和原子控制。
- 错误示范：
if instance == nil { mutex.Lock(); if instance == nil { instance = new(...) } mutex.Unlock() }—— 仍存在竞态风险，且代码冗余 - 正确姿势：只用
once.Do(func(){ instance = &Singleton{...} })，Do内部保证函数仅执行一次且完全完成后再返回 -
sync.Once不可重用，每次都需要独立的once sync.Once变量；重复调用Do不会 panic，但也不会再执行
单例结构体字段是否该导出？取决于使用场景
单例本身是全局访问点，但它的字段是否导出，直接影响外部能否直接修改状态。这不是语法问题，而是契约问题。
- 若单例封装的是只读配置（如
Config），字段可导出，方便直接访问：singleton.Host - 若单例管理的是有状态资源（如连接池、计数器），字段应保持私有，只暴露方法（
GetConn()、Inc()），避免外部绕过逻辑直接改字段 - 导出字段 + 无校验的 setter 方法（如
SetCount(n int)）等于放弃单例的可控性，和裸变量没区别
测试时单例难 mock？别硬测，换思路
单例最难测的点不是“怎么验证它只初始化一次”，而是“如何隔离它对其他测试的影响”。强行在测试中重置 instance 或 once 变量，会导致测试间污染，尤其并行测试（go test -p）下极不稳定。
- 真正该测的是：单例的初始化逻辑本身（比如
newSingletonFromConfig()是否按预期解析 YAML）——把它拆成独立函数单独测 - 业务代码中，不要直接依赖
GetInstance()，而是通过参数注入接口（如func Handle(req *http.Request, s Service)），测试时传 mock 实现 - 如果必须测单例行为，用
init()+ 包级变量的方式反而更容易在测试前重置（因为init()只在包首次导入时运行）
单例真正的复杂点不在实现，而在于“谁该负责销毁”。Go 没有析构函数，GetInstance() 返回的指针永远不会被自动释放；如果单例持有文件句柄、网络连接或 goroutine，这些资源必须显式关闭，且关闭时机很难统一协调——这往往比“怎么创建”更值得花时间设计。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
