sync.Once是最安全的延迟初始化方式，它是Go标准库唯一经验证的并发安全、零成本抽象机制，适用于单例、配置、数据库连接等场景，但需避免在Do中执行I/O或忽略错误处理。
用 sync.Once 是最安全的延迟初始化方式
Go 没有语言级 lazy 关键字，sync.Once 是标准库唯一被验证过、并发安全、零成本抽象的延迟加载机制。别自己写双检锁——容易漏掉 atomic.LoadPointer 或忘记内存屏障，导致偶发 nil panic。
常见错误是把初始化逻辑直接塞进 once.Do 匿名函数里，比如读大文件或连数据库，结果首次调用卡住整个 goroutine。应该只做“赋值”动作，耗时操作提前封装进独立函数。
-
once.Do内部只做 instance 赋值，不执行 I/O、网络、锁等待 - 初始化失败要捕获错误并缓存，避免下次重试（
sync.Once不重试） - 如果需要多次重试或 fallback 逻辑，就别用
sync.Once，改用带状态机的自定义 lazy wrapper
延迟加载必须配合接口隔离，否则等于没做
光把结构体字段设为 *RealService 并延迟 new，不等于实现了访问控制或模块解耦。真正起作用的是：让调用方只依赖接口，而 proxy 实现该接口但不暴露真实类型。
典型反例：type Proxy struct { real *RealLoader } 然后在方法里直接调 p.real.Load() —— 这样只要有人拿到 *Proxy 就能强制类型断言成 *RealLoader，绕过所有代理逻辑。
- 真实对象字段必须是私有（小写首字母），且不导出构造函数
- 对外只暴露接口类型，比如
type DataReader interface { Read() ([]byte, error) } - proxy 结构体不嵌入
RealLoader，只持有一个指针，并在方法中调用其接口方法
Agollo 和 Viper 的延迟加载不是一回事，别混用
Agollo 的 GetConfigCache("ns") 是运行时按需拉取命名空间配置，属于“配置层面的懒加载”；而 Viper 的 ReadInConfig() 是启动时一次性加载全部配置源（file/env/flag），它本身不提供延迟能力。
如果你用 Viper 却想实现“只在某个 handler 里才加载 redis 配置”，那是错的路径——Viper 设计上就是全局配置中心，延迟应由业务层控制（比如把 viper.GetString("redis.url") 包进一个 lazy func），而不是指望 Viper 自己懒。
- Agollo 支持
client.GetConfigAndInit("new-namespace")动态加载，适合模块化配置场景 - Viper 推荐在
init()或main()开头就ReadInConfig()，后续所有GetString调用都是内存读取，无 IO 开销 - 混合使用时，Agollo 可作为 Viper 的 remote source（通过
viper.AddRemoteProvider），但延迟行为仍由 Agollo 控制
internal 目录下延迟加载容易被误引用
企业中台项目要求核心 service 必须放在 internal/ 下，但开发者常忽略一点：延迟加载的 proxy 实例如果定义在 pkg/ 或根目录，就可能被外部模块 import 并直接调用，绕过 internal 的鉴权和限流中间件。
例如：在 pkg/cache/proxy.go 里定义了 GetRedisClient() 返回一个延迟初始化的 *redis.Client，结果前台系统直接 import 并用了——这等于把中台的连接池裸露出去。
- 所有延迟加载的入口函数（如
GetDB()、NewUserService()）必须声明在internal/子包内 - 若需跨模块复用，应通过
internal/api提供 interface + factory 函数，而非暴露具体 client - CI 流水线应加检查：禁止
import语句出现在internal/外部却引用internal/内部符号
延迟加载不是加个 if p.real == nil 就完事，它牵扯到并发安全、错误传播、接口边界、模块可见性四个维度。最容易被跳过的其实是最后一点：没人会去查一个看似“只是初始化慢点”的函数，是否悄悄破坏了 internal 的封装契约。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
