gin 默认路由不支持路径通配符转发，因其路由匹配基于静态前缀与动态参数（:param），而非正则或通配符引擎；正确写法是 router.any("/api/*any", proxyhandler)，变量名必须为 any，通过 c.param("any") 获取子路径。
为什么 Gin 默认路由不支持路径通配符转发？
因为 gin.Engine 的路由匹配是静态前缀 + 动态参数（:param）机制，不是正则或通配符引擎。直接写 router.Any("/api/*path", proxyHandler) 会报错或匹配失效——Gin 没有 * 通配符语法，*path 不被识别为合法参数名。
常见错误现象：404 Not Found 即使路径存在；或 c.Param("path") 返回空字符串；更隐蔽的是某些嵌套路径（如 /api/v2/users/123/profile）只取到 v2 后面部分，丢失层级。
- 正确做法是用
router.Any("/api/*any", proxyHandler)——注意必须是*any，且变量名只能叫any（Gin 内部硬编码） - 在 handler 中通过
c.Param("any")获取完整子路径，例如/v2/users/123/profile - 拼接上游地址时，记得手动去掉开头的斜杠：
upstreamURL.Path = strings.TrimPrefix(c.Param("any"), "/")
如何让 Gin 网关真正“透传”请求头和 body？
默认 c.Request.Body 是一次性读取流，直接转发会导致下游收不到 body；而 c.Request.Header 中部分 header（如 Connection、Transfer-Encoding）会被 Go HTTP client 自动过滤或重写，造成 upstream 服务解析失败。
典型表现：POST 请求 body 为空；下游服务报 invalid JSON；gRPC-web 调用失败；某些鉴权 header（如 X-Forwarded-For）丢失。
- 必须调用
c.Request.Body = io.NopCloser(bytes.NewReader(bodyBytes))重置 body 流（先ioutil.ReadAll(c.Request.Body)缓存） - 手动复制关键 header：
req.Header.Set("X-Real-IP", c.ClientIP())、req.Header.Set("X-Forwarded-For", c.ClientIP()) - 显式清除 Go 自动设置的危险 header：
req.Header.Del("Connection")、req.Header.Del("Transfer-Encoding") - 如果要透传原始 host，别用
c.Request.Host，它可能被反向代理篡改；应从c.Request.Header.Get("Host")取
Gin 中间件里怎么安全地做 JWT 验证并传递用户信息？
JWT 验证不能只校验签名就完事——常见漏洞是忽略 exp、nbf、iss 字段，或把未校验的 sub 直接当用户 ID 用。更麻烦的是，验证后如何把用户信息传给后续 handler，又不污染 c.Keys 导致 key 冲突。
真实踩坑点：多个中间件都往 c.Keys 写 "user_id"，结果后端拿到的是上一个请求残留值；或者 JWT 解析失败却没中断流程，下游直接 panic。
- 用固定 key 命名空间，比如
c.Set("auth.user_id", userID)和c.Set("auth.role", role)，避免裸字符串 - 验证失败必须显式
c.AbortWithStatusJSON(http.StatusUnauthorized, ...)，不能只return - 别在中间件里解析两次 token——token 字符串从
c.GetHeader("Authorization")提取一次，缓存到c.Set("auth.raw_token", tokenStr)供后续复用 - 对
exp校验要留缓冲窗口，比如time.Now().Add(5 * time.Second).After(claims.ExpiresAt.Time)，防时钟漂移
为什么 gin.Default() 不适合生产网关？
gin.Default() 自带 gin.Recovery() 和 gin.Logger()，看似省事，但在高并发网关场景下，Recovery 的 panic 捕获会掩盖真实错误上下文，而默认 Logger 输出格式无法关联 traceID，日志分散难排查。
更严重的是：它默认启用 Content-Type 自动推断，遇到非标准 MIME 类型（如 application/vnd.api+json）会误判，导致下游响应体被截断或乱码。
- 生产环境必须用
gin.New()，自己注册中间件：用zap替代gin.Logger，用prometheus指标暴露 panic 次数而非静默恢复 - 显式设置
router.Use(gin.RecoveryWithWriter(zap.L().Writer()))，把 panic 日志打到结构化日志系统 - 禁用自动 MIME 推断：
router.NoRoute(func(c *gin.Context) { c.Writer.WriteHeader(http.StatusNotFound) })后手动处理 - 若需调试，临时加
gin.DebugPrintRouteFunc查路由表，但上线前必须删掉
Gin 构建网关真正的复杂点不在路由或转发，而在「状态隔离」——每个请求的 context、body、header、认证信息必须严格不跨请求泄漏。很多线上事故，都是因为某个中间件忘了 c.Next() 或误用了全局变量，导致 A 用户的 token 出现在 B 用户的 downstream 请求头里。
