Go需手动实现Proxy模式：定义接口抽象行为，用包装结构体拦截调用；延迟加载须用sync.Once或双检锁防并发panic；访问控制应通过细粒度接口隔离而非if判断；context和defer需透传，生命周期管理需明确资源释放时机。
Go 里没有内置 Proxy 类型，得自己写接口+结构体
Go 不像 JavaScript 或 Java 那样有语言级的代理机制，proxy 是个设计模式概念，不是语法糖。你要实现延迟加载或访问控制，核心是用接口抽象行为，再用一个包装结构体（比如 ProxyService）去拦截调用。
常见错误是直接在 struct 字段里 new 一个真实对象——这会让延迟加载失效；或者把所有方法都写死在 proxy 里，导致每次加新方法都要同步改两处。
- 定义统一接口：比如
type DataLoader interface { Load() ([]byte, error) } - 真实实现放单独结构体：
type RealLoader struct{ path string } - proxy 结构体只持有一个指针（
*RealLoader或nil），首次调用Load()时才初始化 - 不要嵌入
RealLoader，否则会暴露未受控的方法
延迟加载必须检查 nil + 加锁，否则并发 panic
如果多个 goroutine 同时调用 Load()，而 proxy 没做同步，可能触发多次初始化、资源重复打开，甚至 nil pointer dereference 错误。
典型错误写法：if p.real == nil { p.real = &RealLoader{...} } —— 这段代码在并发下不安全。
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Once最省心：func (p *ProxyLoader) Load() ([]byte, error) { p.once.Do(p.init); return p.real.Load() } - 或者用
sync.RWMutex+ 双检锁，但容易写错，不推荐新手用 -
init方法里别做耗时操作（比如读大文件），否则首次调用会被卡住 - 如果初始化可能失败，记得把错误存在字段里，避免下次重试
访问控制要靠接口拆分，不是靠 if 判断
想限制某些用户只能读不能写？别在 proxy 的每个方法里塞 if !user.HasPerm("write") { return err } —— 这会让 proxy 耦合权限逻辑，也违背接口隔离原则。
真正合理的做法是定义更细粒度的接口，让 proxy 实现其中一部分：
- 定义
Reader interface { Read() ([]byte, error) }和Writer interface { Write([]byte) error } - 让
ProxyReader只实现Reader，它根本就没有Write方法可调用 - 需要写权限时，换一个实现了两个接口的
ProxyReadWrite - 这样编译期就报错，比运行时报错早得多
注意 defer 和 context.Context 在 proxy 中的传递
proxy 常被用在 HTTP handler 或数据库访问场景，容易忽略 context.Context 和 defer 的穿透问题。比如你封装了一个带超时的 Do(ctx) 方法，但 proxy 里没把 ctx 传给真实对象，那就白设了超时。
另一个坑是：proxy 方法里开了 goroutine，但没把 ctx 传进去，导致 cancel 信号丢失。
- 所有带
context.Context参数的方法，proxy 必须原样透传，不能用context.Background()替代 - 如果 proxy 自己用了
defer（比如关文件、释放锁），要确认它和真实对象的defer不冲突 - 真实对象返回的
io.Closer如果由 proxy 暴露，proxy 就得负责Close()，不能甩锅
最麻烦的其实是生命周期管理：proxy 本身不持有资源，但它要决定什么时候释放真实对象持有的连接、文件句柄或内存。这个点没人提醒，但线上出问题往往卡在这儿。
