闭包可捕获同包内未导出的包级变量（如var config struct{Host string}），因其作用域允许引用；若config为值类型，闭包捕获初始化副本，后续修改不影响已创建实例；若为指针，则共享地址，修改影响后续闭包调用。
闭包如何捕获未导出的包级变量
Go 中无法直接跨包访问未导出（小写开头）的包级变量，但闭包可以捕获其所在作用域内的变量引用。关键在于：闭包必须定义在变量所在包内，且该变量需为包级变量（而非局部变量），才能被多个实例共享。
-
config必须声明在包顶层，例如var config = struct{ Host string }{"localhost"} - 闭包函数（如
newClient）必须在同一包中定义，才能捕获config的地址 —— 即使config未导出，闭包内部仍可读写它 - 若把
config放在init()或某个函数里，闭包捕获的是副本或已失效的栈地址，行为不可靠
用闭包封装配置并返回可复用的构造函数
典型做法是暴露一个返回函数的函数（即“工厂闭包”），让调用方获得能访问私有配置的实例构造能力。这样既不暴露 config 本身，又支持多实例创建。
func NewClientFactory() func() *Client {
return func() *Client {
return &Client{host: config.Host} // config 是未导出包变量
}
}
- 调用
NewClientFactory()返回一个闭包，该闭包绑定了当前config的值（注意：是值拷贝还是指针取决于config类型；若需动态更新，建议用指针或 sync.Once 初始化的全局指针） - 每个调用该闭包生成的
*Client实例都基于同一份config状态，但彼此独立 - 不能直接返回
func() *Client { return &Client{host: config.Host} }—— 这样会把闭包定义“外泄”到调用方包，失去封装性
修改配置时闭包是否自动感知
闭包捕获的是变量的**当前值**或**地址**，不是快照。但 Go 没有“响应式闭包”，所以是否感知变化，取决于你如何组织数据。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 如果
config是值类型（如struct），闭包捕获的是初始化时的副本，后续修改不影响已创建的实例 - 如果
config是指针（如var config = &Config{Host: "localhost"}），所有闭包共享同一内存地址，修改*config会影响所有后续调用闭包生成的新实例 - 已有实例（如已创建的
*Client）字段不会自动刷新 —— 它们只在构造时读一次config.Host；如需运行时重载，得在Client方法里每次读取*config
为什么不用 init + 全局变量 + 导出函数更简单
因为闭包在这里没有提供额外优势，反而增加理解成本。真正需要闭包的场景是：配置依赖运行时参数（如环境变量、flag 解析结果），且需延迟绑定。
立即学习“go语言免费学习笔记（深入）”；
- 例如：先解析
os.Args，再基于结果生成闭包 —— 此时闭包捕获的是解析后的最终值 - 若配置完全静态（如硬编码或
init()里固定赋值），直接用未导出全局变量 + 导出的NewClient()函数更清晰 - 常见误用：试图用闭包绕过 Go 的导出规则，结果导致测试难 mock、热重载逻辑混乱
闭包传递非导出配置的本质，是利用作用域捕获 + 工厂函数封装。它不解决并发安全，也不自动同步变更 —— 这些都得靠你自己加锁或用 sync.Once 控制初始化时机。
