代理模式非权限控制银弹，需配合外部鉴权策略；应通过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 透传。

• 所有代理方法签名必须保留 ctx context.Context 参数，且将它传给 authorizer 和下游 svc
• 不要在 Proxy 里启动新 goroutine 并丢弃 ctx，例如 go doSomething() 是危险的
• 如果 Authorizer 实现涉及 RPC 调用，确保其 client 设置了 ctx 超时，否则可能拖垮整个请求链

权限控制的复杂性不在代理结构本身，而在于策略一致性、上下文携带、错误归因和 fallback 行为——这些才是实际项目里卡住进度的地方。