Go中代理层权限控制通过接口抽象+结构体封装+中间件实现，HTTP用httputil.NewSingleHostReverseProxy包装ServeHTTP，gRPC用UnaryServerInterceptor，关键在鉴权前置、上下文透传与错误脱敏。
Go 语言中没有原生的“代理模式”语法支持，所谓代理层权限控制，本质是通过接口抽象 + 结构体封装 + 中间件式调用链来实现。直接在 http.Handler 或 RPC 客户端/服务端注入校验逻辑，比模拟 Java 那种动态代理更轻量、也更符合 Go 的设计哲学。
如何用 http.Handler 实现带权限校验的 HTTP 代理
最常见场景：反向代理请求前检查 JWT 或 API Key。别自己重写转发逻辑，优先复用 net/http/httputil.NewSingleHostReverseProxy，然后包装它的 ServeHTTP 方法。
关键点：
- 权限校验必须放在
Director函数之前，否则可能绕过检查 - 校验失败时直接写响应并 return，避免调用
proxy.ServeHTTP - 不要在
Director里修改req.URL后再做鉴权——此时 URL 已被重写，原始路径信息可能丢失
func NewAuthProxy(target *url.URL) http.Handler {
proxy := httputil.NewSingleHostReverseProxy(target)
proxy.Director = func(req *http.Request) {
req.Header.Set("X-Forwarded-Host", req.Host)
req.URL.Scheme = target.Scheme
req.URL.Host = target.Host
}
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if !isValidAPIKey(r.Header.Get("X-API-Key")) {
http.Error(w, "Forbidden", http.StatusForbidden)
return
}
proxy.ServeHTTP(w, r)
})
}
grpc.UnaryServerInterceptor 是 gRPC 代理层权限控制的核心入口
gRPC 没有“代理对象”，但拦截器（interceptor）就是天然的代理层。所有 unary 调用都会经过 UnaryServerInterceptor，它接收原始 ctx、req、方法名和 handler，完全可控。
立即学习“go语言免费学习笔记（深入）”；
注意细节：
- 方法名形如
"/package.Service/Method"，可用于白名单路由控制 - 从
ctx提取 token 时，优先用grpc.Peer和metadata.FromIncomingContext，不是r.Header - 拦截器里不要直接调用
handler()，而是用next(ctx, req)—— 否则会跳过后续拦截器
func AuthInterceptor(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) {
md, ok := metadata.FromIncomingContext(ctx)
if !ok || len(md["authorization"]) == 0 {
return nil, status.Error(codes.Unauthenticated, "missing auth header")
}
if !validateToken(md["authorization"][0]) {
return nil, status.Error(codes.PermissionDenied, "invalid token")
}
return handler(ctx, req)
}
为什么不该用结构体字段代理（如嵌入 *http.Client）来控制权限
常见误区：定义一个 type AuthClient struct { client *http.Client }，然后在每个方法里加校验。这看似是代理模式，实际会引发三个问题：
- 无法拦截底层连接建立、重试、超时等行为，权限只覆盖到“发起请求前”，不覆盖整个生命周期
- 如果业务代码直接调用
client.Do绕过你的封装，权限就失效了 - 对第三方库（如
github.com/aws/aws-sdk-go）几乎不可控，它们内部构造自己的http.Client
真正可控的方式，是把权限逻辑下沉到 Transport 层（如自定义 http.RoundTripper），或统一用中间件注册机制（如 gin 的 Use、grpc 的 interceptor）。
代理层权限容易被忽略的边界：上下文传递与错误透传
代理不是简单转发，还要保证 trace ID、用户身份、租户信息能透传到下游，同时错误不能暴露敏感细节。
- HTTP 场景下，用
X-Request-ID和X-User-ID等标准头透传；gRPC 用metadata.MD附加字段 - 下游返回 403/401 时，代理层应重新包装错误（比如把具体 reason 替换为通用提示），防止泄露后端权限模型
- 日志里记录原始请求头时，必须脱敏
Authorization、Cookie等字段，否则审计过不了
权限控制最难的部分从来不是“怎么写 if 判断”，而是“判断之后，上下文怎么安全流转、错误怎么合理折叠、日志怎么既可查又合规”。这些细节不处理好，代理层反而成了攻击面放大器。
