go中延迟加载必须用sync.once，因if判空非原子操作，多goroutine并发时会重复初始化导致panic；sync.once是官方唯一推荐的零分配、线程安全、不可重置的“只执行一次”原语。
延迟加载必须用 sync.Once，不是靠 if 判断
并发下直接判空初始化会 panic，比如 if p.real == nil { p.real = newReal() } 这种写法在 10 个 goroutine 同时调用时，可能触发 10 次 newReal()，资源重复打开、内存泄漏、甚至 nil pointer dereference。正确路径只有一条：sync.Once 是 Go 官方为「仅执行一次」场景设计的零分配同步原语。
常见错误还包括把耗时操作塞进 once.Do() 里——比如在 init() 中读取远程配置或建立数据库连接，会导致首次调用被卡住几百毫秒。应该只做轻量初始化（如赋值指针），把重活交给后续方法按需触发。
-
sync.Once不可重置，也不支持带返回值的初始化函数，错误需提前存到字段里 - 如果初始化可能失败（如网络不可达），建议加一个
err error字段，在Do()里统一捕获并缓存 - 别用
sync.RWMutex手写双检锁——Go 1.9+ 的sync.Once已优化为无锁 fast-path，性能更好也更安全
代理结构体不能嵌入真实对象，否则破坏封装边界
很多人图省事写 type Proxy struct { RealService } ，结果所有 RealService 的方法自动暴露，权限控制、日志、熔断等逻辑全失效。Proxy 的核心价值是拦截，不是继承。
正确做法是显式持有指针：real *RealService，并在每个方法里手动转发。虽然多几行代码，但换来的是可控性：
- 可以在
Get()前校验权限，在Delete()前打审计日志 - 能对特定方法做降级（比如
Update()返回缓存旧值，Get()仍走真实调用） - 避免因上游接口新增方法导致 Proxy 编译不通过却悄悄透传——那是线上事故温床
高并发下延迟加载要防「雪崩式初始化」
单机 QPS 上万时，如果 1000 个 goroutine 同时首次访问某个延迟加载字段，sync.Once 虽能保底不 panic，但所有请求会排队等第一个初始化完成，造成毛刺和长尾延迟。
这不是理论问题：某风控服务在早高峰就因 cache2go 实例的延迟加载引发 300ms+ P99 延迟。解决方案不是去掉延迟加载，而是分层预热：
- 启动时用 goroutine 异步触发关键 Proxy 的
Load()，不阻塞 main - 对非核心路径（如管理后台配置），允许带超时的懒加载：
ctx, cancel := context.WithTimeout(ctx, 500*time.Millisecond) - 把「加载失败后是否重试」策略外置，比如失败后退化为默认值，而不是死等
配置类延迟加载最容易忽略刷新机制
很多团队用 sync.Once 加载一次配置就完事，结果配置中心更新后服务永远读不到新值。延迟加载 ≠ 一劳永逸。
真正可用的方案得组合三要素：sync.Once（首次加载）、time.Ticker（定期检查变更）、atomic.Value（无锁替换最新配置）。不要用 mutex 包裹整个配置 map——那是性能瓶颈。
特别注意环境变量或 flag 配置：它们本就是进程启动时读取的静态值，强行套延迟加载反而增加复杂度，属于典型误用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
