gin.default()不能用于生产网关，因其默认启用logger（明文输出authorization等敏感字段）和recovery（不记录panic堆栈）、无tls配置能力；生产必须禁用默认中间件，显式构造受控链。
为什么 gin.Default() 不能直接用于生产网关
它默认启用 gin.Logger 和 gin.Recovery，但日志明文输出敏感字段（如 Authorization 头、请求体）、panic 恢复后不记录上下文堆栈、无 TLS 配置能力——这些在网关层会直接暴露认证凭据或服务拓扑。生产网关必须禁用默认中间件，显式构造受控链。
如何让 Gin 与 gRPC 后端建立带证书的 TLS 连接
Gin 本身不处理下游通信，关键在你调用 gRPC 客户端时是否启用 mTLS。常见错误是只配了服务端证书，却忽略客户端证书校验：
- 服务端（如 user 模块）需启用
grpc.Creds(credentials.NewTLS(&tls.Config{ClientAuth: tls.RequireAndVerifyClientCert})) - Gin 网关侧必须加载客户端证书和私钥：
credentials.NewTLS(&tls.Config{Certificates: []tls.Certificate{cert}, RootCAs: caPool}) - 若用
grpc.Dial连 serviceHub 或业务模块，务必传入grpc.WithTransportCredentials，而非grpc.WithInsecure()
漏掉任一环，连接会降级为明文或被拒绝，且错误常表现为 connection refused 或 transport: authentication handshake failed，而非明确的证书错误。
JWT 校验中间件里最容易被绕过的坑
很多实现只校验签名和过期时间，却忽略 issuer、audience 和 nbf（not before）字段。攻击者可伪造 issuer 为内部服务名，骗过网关转发到未授权模块。正确做法：
- 从配置加载可信
issuer列表（如["gateway.example.com", "auth-service.example.com"]） - 校验
aud是否包含当前路由目标服务 ID（例如/user/login→aud: "user-service"） - 使用
github.com/golang-jwt/jwt/v5的Validate方法，而非手动取claims["exp"]
另外，Authorization 头值应以 "Bearer " 开头严格匹配，空格不可省略；否则 Bearerxxx 会被误解析为 token。
HTTP/2 与 TLS 1.3 在 Gin 网关中的真实约束
Gin 运行在 net/http 之上，要启用 HTTP/2 必须满足两个硬性条件：
- 服务必须使用 TLS（即
r.RunTLS()或自定义http.Server+TLSConfig），纯 HTTP 不支持 HTTP/2 -
TLSConfig.MinVersion至少设为tls.VersionTLS12，但推荐tls.VersionTLS13—— Go 1.20+ 默认支持，且能规避 TLS 1.2 的重协商漏洞
若你用反向代理（如 Nginx）终止 TLS，再以 HTTP 转发给 Gin，则上游 HTTP/2 特性（如流优先级、头部压缩）全部丢失，gRPC 流式响应也会退化为 chunked HTTP/1.1。
安全通道不是加个 TLS 就完事；证书链完整性、JWT 声明语义、协议版本对齐，三者缺一不可。尤其在网关这种承上启下的位置，一处宽松等于全局失守。
