Go代理模式需先定义接口，再由真实对象和代理对象共同实现；缓存代理须处理并发、过期与空值；HTTP代理应包装RoundTripper而非http.Client；代理若启goroutine必须提供Close方法。
代理模式在 Go 里没有语言级支持，得靠接口 + 结构体手动组合
Go 没有 class、继承或 dynamic proxy 机制，所以没法像 Java 那样用 java.lang.reflect.Proxy 自动生成代理。必须显式定义接口，再让真实对象和代理对象都实现它——这是所有 Go 代理实现的起点。
常见错误是直接给 struct 加方法却不提取接口，导致代理无法替换真实对象。比如写了个 UserService struct，但没定义 UserRepository 接口，后续就无法插入日志、缓存等代理逻辑。
- 先写接口：例如
type DataFetcher interface { Fetch(id string) ([]byte, error) } - 真实类型实现该接口：
type HTTPFetcher struct{}+func (h HTTPFetcher) Fetch(...) - 代理类型也实现同一接口：
type CacheProxy struct { fetcher DataFetcher; cache map[string][]byte }+func (c CacheProxy) Fetch(...)
缓存代理要小心并发读写和过期策略
用 sync.Map 或 sync.RWMutex 保护共享缓存是基本操作，但容易忽略两点：一是缓存穿透（空结果未缓存），二是过期时间硬编码导致难测试。
建议把过期逻辑抽成可选参数，用 time.Time 字段或函数判断是否过期，而不是固定用 time.Now().Add(5 * time.Minute) 写死。
立即学习“go语言免费学习笔记（深入）”；
type CacheEntry struct {
data []byte
valid func() bool // 可注入 mock 时间判断，便于单元测试
}- 避免直接用
map[string][]byte：并发写 panic - 不要在
Fetch中无条件重置过期时间：会导致热点 key 永远不淘汰 - 空结果建议缓存为
nil+ 单独标记（如cache.SetEmpty(id)），防止反复查 DB
HTTP 客户端代理常用在中间件链中，别直接包装 http.Client
想给 HTTP 请求加超时、重试、指标上报？别去嵌套或重写 http.Client，而是包装 http.RoundTripper。Go 的 http.Client 本身支持替换底层传输器，这才是标准做法。
典型错误是试图用匿名字段嵌入 http.Client 并覆盖 Do 方法——这会绕过 Client 自身的 redirect、cookiejar 等逻辑，且无法复用连接池。
- 实现
RoundTripper接口，例如type MetricsRoundTripper struct { next http.RoundTripper } - 在
RoundTrip方法里调用next.RoundTrip(req)前后插逻辑 - 创建 client 时传入：
&http.Client{Transport: &MetricsRoundTripper{next: http.DefaultTransport}}
代理对象生命周期管理不当，容易引发 goroutine 泄漏或 panic
代理如果启动了后台 goroutine（比如定期刷新 token、清理缓存），必须提供 Close() 或 Stop() 方法，并在使用方明确调用。Go 不会自动析构，也没有 finalizer 可靠兜底。
尤其注意带 channel 的代理：未关闭的 channel + 阻塞的 select 会锁住 goroutine，且无法被 GC 回收。
- 所有启动 goroutine 的代理结构体，应实现
io.Closer接口 - channel 发送前检查是否已关闭（用
select { case ch 避免阻塞） - 在
Close()中 close channel、cancelcontext.Context、sync.WaitGroup.Wait()
最常被忽略的是代理嵌套层级过深——比如 A 代理 B，B 代理 C，C 代理 D，每个都带自己的资源管理逻辑。这时候必须约定清楚谁负责释放、谁只转发 Close，否则极易漏关或重复关。
