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) 写死。
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 本身支持替换底层传输器，这才是标准做法。
