Golang代理模式如何控制访问权限_代理层设计技巧

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 New
AuthProxy(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，完全可控。

注意细节：

• 方法名形如 "/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 判断”，而是“判断之后，上下文怎么安全流转、错误怎么合理折叠、日志怎么既可查又合规”。这些细节不处理好，代理层反而成了攻击面放大器。