闭包通过捕获外部变量实现变量只初始化一次：首次调用执行初始化并缓存结果，后续直接返回缓存值；需避免每次调用都新建闭包，正确做法是定义并立即执行闭包，将结果赋给变量。
闭包如何让变量只初始化一次
Go 里没有“静态局部变量”，但闭包能模拟这种行为：把初始化逻辑和状态封装在函数内部，首次调用时执行初始化，后续调用直接返回缓存结果。sync.Once 虽然更安全，但闭包更轻量、无锁、适合纯计算或单次资源加载场景。
常见错误是把闭包写成每次调用都新建一次，比如：func() string { return expensiveInit() }()——这没闭包什么事，每次都执行。正确写法是定义并立即调用一个闭包，把结果捕获进外部变量：
var getDBConn = func() *sql.DB {
db, err := sql.Open("mysql", "user:pass@/dbname")
if err != nil {
panic(err)
}
return db
}()
这里 getDBConn 是一个变量，类型为 *sql.DB，不是函数；闭包只执行一次，sql.Open 也只调一次。
带参数的延迟初始化怎么写
如果初始化需要运行时参数（比如配置名、环境标识），就不能用上面那种“零参闭包”，得返回一个函数，靠外层函数接收参数、内层闭包捕获初始化结果。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：把参数传进立即执行闭包——参数在包初始化时就固定了，失去“按需”意义
- 正确思路：外层函数返回闭包，闭包内部做懒加载 + 缓存，参数由调用方传入
示例：按数据库名加载不同连接：
func makeDBLoader() func(string) *sql.DB {
cache := make(map[string]*sql.DB)
return func(name string) *sql.DB {
if db, ok := cache[name]; ok {
return db
}
db, err := sql.Open("mysql", "user:pass@"+name)
if err != nil {
panic(err)
}
cache[name] = db
return db
}
}
loader := makeDBLoader()
db1 := loader("prod")
db2 := loader("test")
注意 cache 在闭包作用域内，每个 loader 实例独享一份缓存；若多个 goroutine 并发调用，需加 sync.RWMutex 或改用 sync.Map。
闭包延迟加载与资源释放的配合问题
闭包只管“加载”，不自动管“释放”。如果加载的是文件句柄、网络连接、内存缓冲区等需显式清理的资源，必须手动设计释放路径，否则会泄漏。
- 不能依赖 GC 回收
*os.File或net.Conn——它们底层持有 OS 句柄，GC 不保证及时释放 - 闭包返回的对象最好自带
Close()方法，或额外暴露一个清理函数 - 避免在闭包里直接
defer——defer 在闭包定义时就绑定，不是在调用时执行
推荐模式：闭包返回结构体，含初始化字段和方法：
type DBPool struct {
db *sql.DB
once sync.Once
}
func (p *DBPool) Get() *sql.DB {
p.once.Do(func() {
p.db = sql.Open("mysql", "...")
})
return p.db
}
func (p *DBPool) Close() error {
return p.db.Close()
}
这样既延迟初始化，又明确释放责任，比纯闭包更易维护。
为什么不用 sync.Once 替代闭包
sync.Once 确实更线程安全，但闭包有它不可替代的场景：
- 闭包可捕获任意上下文变量（如 logger、config、context.Context），
sync.Once只能配合全局或方法级变量使用 - 闭包支持“多实例”隔离：每个闭包有自己的缓存，适合构建可复用的组件工厂（如不同租户的配置加载器）
- 闭包天然支持“重置”：只要重新赋值闭包变量，就能清空状态；而
sync.Once一旦完成就不可重置
真正要注意的是：闭包本身不提供并发保护。如果多个 goroutine 同时首次调用同一个闭包变量（如上面的 getDBConn），可能触发多次初始化。这种情况必须用 sync.Once 或互斥锁兜底，不能只靠闭包。
