不用net/http直接转发而选gin或gorilla/mux，因前者易忽略body重放、header透传、超时等细节；gin适合需鉴权限流的网关，gorilla/mux更轻量适配纯代理场景。
为什么不用 net/http 直接转发，而要引入 gorilla/mux 或 gin-gonic/gin
直接用 net/http 做反向代理容易忽略请求体重放、头部透传、超时控制等细节，导致下游服务收到不完整请求或连接被意外关闭。比如 http.DefaultTransport 默认不设置 MaxIdleConnsPerHost，高并发下会快速耗尽文件描述符。
选 gin 主要是它内置了中间件链、路径参数提取和错误统一处理能力，比手写 http.ServeMux 更可控；gorilla/mux 则更轻量，适合只做路由匹配+代理的场景。
-
gin适合需要鉴权、限流、日志埋点等扩展逻辑的网关 -
gorilla/mux更适合纯协议转换层（如 HTTP → gRPC）或低延迟要求极高的边缘网关 - 两者都支持
ReverseProxy封装，但gin的c.Request是可读写的，方便改写Host、X-Forwarded-For等头
如何安全地把请求代理到下游服务而不丢失 body 和 header
Go 的 http.ReverseProxy 默认会修改部分 header（如 Connection、Transfer-Encoding），且原始 Request.Body 在第一次读取后就不可再读——这会导致下游服务收不到 body。
必须显式复制 body 并重置 Request.Body，同时手动保留关键 header：
立即学习“go语言免费学习笔记（深入）”；
func NewSingleHostReverseProxy(dirURL *url.URL) *httputil.ReverseProxy {
proxy := httputil.NewSingleHostReverseProxy(dirURL)
proxy.Director = func(req *http.Request) {
req.Header.Set("X-Forwarded-Host", req.Host)
req.Header.Set("X-Forwarded-Proto", "http")
if clientIP := req.Header.Get("X-Real-IP"); clientIP != "" {
req.Header.Set("X-Forwarded-For", clientIP)
}
req.URL.Scheme = dirURL.Scheme
req.URL.Host = dirURL.Host
// 必须重置 Body，否则下游读不到
if req.Body != nil {
bodyBytes, _ := io.ReadAll(req.Body)
req.Body = io.NopCloser(bytes.NewBuffer(bodyBytes))
}
}
return proxy
}
- 别依赖
req.Body多次读取，Go 的io.ReadCloser不是 rewindable -
X-Forwarded-For要从可信入口（如 Nginx）获取，不能直接信任客户端传入的值 - 如果下游是 gRPC，需用
grpc-go的http2.Transport替换默认 transport
如何在网关层做简单的 JWT 验证而不拖慢吞吐
JWT 验证本身不重，但每次解析 + 校验签名 + 检查 exp 如果不做缓存，会成为瓶颈。尤其当密钥是远程 JWKS 端点时，网络延迟不可控。
推荐做法：用内存缓存公钥（TTL 控制在 5–10 分钟），并用 golang-jwt/jwt/v5 的 ParseWithClaims 配合预设 KeyFunc：
var jwtKey = []byte("your-secret-key")
func authMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
authHeader := c.GetHeader("Authorization")
if authHeader == "" {
c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "missing token"})
return
}
tokenStr := strings.TrimPrefix(authHeader, "Bearer ")
token, err := jwt.Parse(tokenStr, func(token *jwt.Token) (interface{}, error) {
if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
return nil, fmt.Errorf("unexpected signing method: %v", token.Header["alg"])
}
return jwtKey, nil
})
if err != nil || !token.Valid {
c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "invalid token"})
return
}
c.Next()
}
}
- 生产环境不要硬编码
jwtKey，应从环境变量或 Vault 加载 - 若使用 RS256，务必缓存
*rsa.PublicKey，避免每次解析都调 JWKS 接口 - 对非敏感接口（如公开文档页），建议跳过验证，用路由分组控制中间件作用域
为什么网关启动后能跑通，压测时却频繁报 dial tcp: lookup xxx: no such host
这不是 DNS 配置问题，而是 Go 默认的 net.Resolver 使用系统 /etc/resolv.conf，在容器化部署中常因 ndots 设置或 DNS 缓存失效导致解析失败。更隐蔽的是：Go 1.19+ 默认启用 net/http 的连接池复用，但若下游服务地址是域名，每次新建连接都会触发 DNS 查询。
- 用
http.Transport的ResolveTCPAddr预解析并缓存 IP，或直接在配置里写 IP（适用于固定后端） - 设置
transport.MaxIdleConnsPerHost = 100，避免连接池爆炸 - 在 Kubernetes 中，确保网关 Pod 的
dnsPolicy: ClusterFirst且ndots不超过 5 - 用
dig +short your-service.default.svc.cluster.local验证集群内 DNS 是否可达，而不是只测外网域名
微服务网关真正的复杂点不在转发逻辑，而在边界控制——超时怎么设、熔断阈值怎么调、日志字段是否包含 traceID、健康检查路径是否暴露给上游。这些细节没对齐，服务一上量就会连环超时。
