Go中代理模式通过接口+结构体组合实现访问控制、缓存和HTTP中间件，需注意权限校验、缓存生命周期、并发安全、依赖注入及测试隔离。
代理模式在 Go 中如何实现访问控制
Go 本身没有语言级的代理关键字，但通过接口 + 结构体组合可以自然实现代理逻辑。核心是让代理类型持有真实对象（或其接口），并在方法调用前后插入权限校验。
常见错误是直接代理指针导致 nil panic，或忘记将代理结构体实现完整接口——编译器不会自动补全未实现的方法。
- 定义统一接口（如
ResourceService），所有真实服务和代理都实现它 - 代理结构体中嵌入真实服务字段（
service ResourceService），而非继承 - 在代理方法中先调用
checkPermission(ctx)，再转发（s.service.DoSomething()） - 权限检查失败时直接返回错误，不调用下游；注意上下文取消需同步传递
type AuthProxy struct {
service ResourceService
auth Authenticator
}
func (p *AuthProxy) GetData(ctx context.Context, id string) ([]byte, error) {
if !p.auth.CanRead(ctx, id) {
return nil, errors.New("access denied")
}
return p.service.GetData(ctx, id)
}
用 Go 代理做缓存时要注意什么
缓存代理的关键不是“存数据”，而是控制缓存生命周期、避免击穿与雪崩。Go 的 sync.Map 或第三方库（如 groupcache）可做底层存储，但代理层必须处理并发安全与过期逻辑。
容易踩的坑：用 time.Now().After(expiry) 做过期判断，却忽略缓存项可能被并发写入后未更新 expiry 字段；或对非幂等操作（如 POST）也加缓存。
立即学习“go语言免费学习笔记（深入）”；
- 只对 GET 类只读方法做缓存代理，写操作直接透传
- 缓存键应包含参数哈希（
fmt.Sprintf("%s:%s", method, hash(args))），避免字符串拼接引入歧义 - 使用
sync.Once或singleflight.Group防穿透，尤其在缓存失效瞬间 - 设置合理 TTL，且缓存值结构中显式携带
expiry time.Time，而非依赖外部定时清理
type CacheProxy struct {
service ResourceService
cache *sync.Map // key: string, value: cacheEntry
}
type cacheEntry struct {
data []byte
expiry time.Time
}
func (p *CacheProxy) GetData(ctx context.Context, id string) ([]byte, error) {
key := "get:" + id
if v, ok := p.cache.Load(key); ok {
entry := v.(cacheEntry)
if time.Now().Before(entry.expiry) {
return entry.data, nil
}
}
data, err := p.service.GetData(ctx, id)
if err == nil {
p.cache.Store(key, cacheEntry{
data: data,
expiry: time.Now().Add(5 * time.Minute),
})
}
return data, err}
HTTP Handler 层的代理模式实践
Go 的 http.Handler 天然适合代理：中间件本质就是请求/响应链上的代理。不要重复造轮子封装“通用代理结构体”，而应复用 http.Handler 接口和 http.HandlerFunc 转换能力。
典型误用是把日志、鉴权、缓存逻辑耦合进业务 handler 内部，导致不可复用；或者在代理中修改了 ResponseWriter 却没正确拦截 WriteHeader，造成 HTTP 状态码丢失。
- 用闭包函数包装原始 handler（
func(http.Handler) http.Handler）是最轻量的代理构造方式 - 若需共享状态（如缓存实例），用结构体实现
http.Handler并在ServeHTTP中调用内部字段 - 代理响应时，务必用
httptest.ResponseRecorder或自定义ResponseWriter包装，否则无法捕获 body 和 status - 注意
context.WithValue传递的 key 类型要全局唯一，避免不同代理层 key 冲突
代理对象的初始化与依赖注入陷阱
代理不是装饰器，它的生命周期和依赖必须明确管理。常见问题是把代理当成无状态工具函数，结果缓存、连接池、认证客户端等依赖被多次初始化或泄漏。
最隐蔽的问题：在单元测试中 mock 真实服务时，忘记同时 mock 代理依赖（如 Authenticator），导致测试实际走网络或 panic。
- 代理结构体的所有依赖（如
cache,auth,service）应在构造时传入，禁止在方法内 new - 若代理含资源（如连接池），提供
Close()方法并文档化调用义务 - 使用 Wire 或 Dig 做依赖注入时，代理类型必须声明为 distinct binding，避免与真实服务类型混淆
- 测试代理行为时，用接口隔离依赖，而不是测试代理是否“调用了某 SDK”
真正难的从来不是写一个代理结构体，而是决定哪些逻辑该放进去、哪些该交给更上层的中间件，以及怎么让它的生命周期和错误传播不破坏原有调用链。
