代理模式非权限控制银弹，需配合外部鉴权策略；应通过interface+struct实现轻量代理层，Proxy持Service和Authorizer接口，方法调用前校验权限；HTTP层宜用中间件+context传递权限信息，并确保ctx超时与goroutine安全。
代理模式不是权限控制的银弹
直接用 Go 实现代理模式来“做权限控制”，容易陷入设计过重、侵入性强、维护成本高的陷阱。代理模式本身只负责“转发+拦截”，它不定义“谁有权限”“权限怎么校验”，这些必须由外部策略（如 RBAC 模块、JWT 解析器、ACL 列表）提供。如果把鉴权逻辑硬塞进代理对象里，会导致 Proxy 类膨胀、难以测试、违反单一职责。
用 interface + struct 实现轻量代理层
真正实用的做法是：让真实服务实现某个 interface，代理结构体也实现同一接口，并在方法调用前插入检查逻辑。关键在于“不修改原服务代码”，且“检查逻辑可替换”。
-
Proxy结构体持有一个Service接口字段和一个Authorizer接口字段 -
Authorizer定义CanAccess(ctx context.Context, method string, resource string) error，便于 mock 和切换策略（如 DB 查询 / Redis 缓存 / 静态配置） - 每个被代理的方法都先调
authorizer.CanAccess，失败直接返回错误，不调用下游 - 避免在
Proxy中处理具体 token 解析或 role mapping，那属于Authorizer的实现细节
type UserService interface {
GetProfile(ctx context.Context, id string) (*User, error)
UpdateEmail(ctx context.Context, id string, email string) error
}
type AuthProxy struct {
svc UserService
authorizer Authorizer
}
func (p *AuthProxy) GetProfile(ctx context.Context, id string) (*User, error) {
if err := p.authorizer.CanAccess(ctx, "GetProfile", "user:"+id); err != nil {
return nil, err
}
return p.svc.GetProfile(ctx, id)
}
Context 传递与中间件风格更自然
在 HTTP handler 层，强行套用经典代理模式反而别扭。更符合 Go 习惯的是用 http.Handler 链式中间件 + context.WithValue 注入权限信息。比如：
- 前置中间件解析 JWT，提取
userID和roles，写入ctx -
路由 handler 内部再根据
ctx.Value("roles")做细粒度判断，或调用统一CheckPermission(ctx, "update:post") - 这样既复用了标准库生态，又避免了为每个 service 手动写 proxy 结构体
- 注意：
context.WithValue存的是只读数据，不要传可变结构体；权限检查失败应返回http.Error或自定义 error，而非 panic
容易忽略的边界：goroutine 安全与超时传递
代理层若不做处理，会丢失上游设置的 ctx.Timeout 或 ctx.Done，导致下游调用无法响应 cancel。同时，若 Authorizer 是网络依赖（如调用 authz 服务），它自身也必须支持 ctx 透传。
立即学习“go语言免费学习笔记（深入）”；
- 所有代理方法签名必须保留
ctx context.Context参数，且将它传给authorizer和下游svc - 不要在
Proxy里启动新 goroutine 并丢弃ctx，例如go doSomething()是危险的 - 如果
Authorizer实现涉及 RPC 调用，确保其 client 设置了ctx超时，否则可能拖垮整个请求链
权限控制的复杂性不在代理结构本身，而在于策略一致性、上下文携带、错误归因和 fallback 行为——这些才是实际项目里卡住进度的地方。
