必须在自定义http.Handler.ServeHTTP入口处、读取req.Body前完成权限校验；延迟加载需用lazy.Group替代sync.Once以支持重试与超时，并发初始化须用sync.Once或RWMutex保障安全。
延迟加载在 HTTP 代理中必须解决权限校验时机问题
权限控制不能塞到 http.Transport.RoundTrip 里——你根本拿不到原始请求头；也不能等转发完再验，响应都发出去了。唯一稳的位置是自定义 http.Handler.ServeHTTP 入口，在读取 req.Body 前完成校验。
常见错误现象：token 解析放在 body 读取之后，导致后续 req.Body 为空，转发失败；或者用 httputil.ReverseProxy 硬套，发现压根插不进校验逻辑。
- 从
r.Header.Get("Authorization")提取 token，立即解析并验证有效性 - 校验失败直接调用
http.Error(w, ...)返回，不往下走 - 成功后才调用
p.getBackend(r.Host)触发后端延迟加载 - 别在 handler 里直接
io.ReadAll(req.Body)，要用req.Body = ioutil.NopCloser(...)恢复可读性（如需复用）
sync.Once 不够用时，lazy.Group 是更现实的选择
sync.Once 是一锤子买卖：初始化函数 panic 或返回 error，后续所有调用都卡死在阻塞状态，无法重试。真实后端服务（比如配置中心、数据库连接池）启动失败很常见，你不该让整个代理不可用。
用 golang.org/x/sync/lazy 的 lazy.Group 才能支持失败后自动重试、超时控制和依赖隔离。
立即学习“go语言免费学习笔记（深入）”；
-
lazy.Group的Do方法签名是func() (T, error)，天然适配可能失败的初始化 - 每次调用都会尝试执行初始化函数，失败后下次还能再来，不会永久挂住
- 适合场景：下游服务偶发不可用、健康检查失败、配置拉取超时等非致命错误
- 注意别把耗时操作（如远程 fetch 配置）写死在
Do函数里，应加 context.WithTimeout 控制单次尝试
延迟加载结构体字段时，并发安全不是“可选”，而是“必做”
很多人以为只要字段初始化一次就够了，结果上线后偶发 nil pointer dereference 或重复初始化。根本原因是没处理并发竞争：多个 goroutine 同时进入 if p.real == nil 分支，都执行 new 操作。
典型错误写法：if p.real == nil { p.real = &RealService{} } —— 这段代码在高并发下必然出事。
- 必须用
sync.Once或sync.RWMutex+ 双检锁（推荐前者） - 初始化函数里别做阻塞操作，否则首次调用会被卡住，影响整个请求链路
- 如果初始化可能失败，要把 error 存到结构体字段里，避免每次重试都触发相同失败路径
- 别嵌入真实结构体（
struct{ *RealService }），会暴露未受控方法，破坏接口隔离
Agollo 多命名空间 + 延迟加载是微服务配置管理的标配组合
在复杂微服务系统中，一次性加载全部配置（比如 database、redis、mq 三个 namespace）既拖慢启动，又浪费内存。Agollo 的延迟加载机制配合多命名空间，能真正实现“按需加载”。
实际部署中，经常看到团队把所有配置塞进一个 application namespace，结果每次改个缓存配置都要重启整个服务。
- 初始化时只传核心 namespace，比如
"application"，其他留空 - 运行时按业务模块调用
client.GetConfigCache("database")触发加载 - 动态添加命名空间要防重复注册，建议加
sync.Map缓存已加载 key - 注意
GetConfigCache不是线程安全的，高并发首次调用仍需加锁或用 lazy.Group 封装
延迟加载真正的难点不在“怎么写”，而在“什么时候不该用”：比如高频调用的小对象、无副作用的纯计算值、或生命周期短于请求周期的资源——强行懒加载反而增加判断开销和代码复杂度。是否延迟，得看初始化成本、使用频次、失败容忍度三者的平衡。
