结论是用gin.default()启动+url.path透传+自定义transport可跑通代理网关，但线上必须配置timeout（5–8秒）、idleconntimeout（30秒）、maxidleconnsperhost（100–200），并单独实现带jitter的重试中间件，同时校准系统时间并注入jwt时间容差校验，否则易雪崩。
直接上结论：用 gin.Default() 启动 + c.Request.URL.Path 透传 + 自定义 http.Transport，就能跑通一个可用的代理网关；但线上不能只靠这个，关键在超时、重试、连接复用三处配置，否则后端抖一下，网关就雪崩。
为什么不用 gorilla/mux 做代理路由层
常见错误是把 gorilla/mux 当默认路由选——它确实支持 Vars(r) 提取路径参数，但 http.Handler 链松散，中间件漏掉 recover 就 panic 整个进程。而网关必须稳：一次 502 不该让所有请求挂掉。
-
gin的c.AbortWithStatus(401)能明确中断链，后续中间件不执行 -
c.Param("id")返回string，比gorilla/mux.Vars(c.Request)["id"]（interface{}）更安全，避免运行时 panic -
gin.Engine底层仍是net/http，所有自定义http.RoundTripper可直接塞进c.Request.Context()，无缝接入
代理转发必须改的 Transport 三项参数
别用 http.DefaultTransport，它对下游波动毫无抵抗力：DNS 缓存过长、空闲连接卡死、单次超时固定 30 秒——这些会让网关变成故障放大器。
-
Timeout：设为 5–8 秒（比下游服务 P99 高 2 秒），太短误杀正常请求，太长拖垮并发 -
IdleConnTimeout：设为 30 秒，和主流后端（如 Nginx、Gin 服务）的 keep-alive timeout 对齐，防止僵死连接占满 fd -
MaxIdleConnsPerHost：建议 100–200，避免文件描述符耗尽；别设成 0 或math.MaxInt32
重试逻辑不要塞进 Transport，单独写中间件：只对 502/503/504 和 net.ErrClosed、context.DeadlineExceeded 重试 1 次，并加 jitter 避免瞬时重试风暴。
JWT 鉴权中间件里 token is expired 总报错
八成不是 token 真过期，而是网关服务器时间没同步。jwt-go 的 exp 是绝对时间戳（Unix 秒），误差 >1 秒就拒绝——而 systemd-timesyncd 默认 5 分钟同步一次，压测时完全不够。
- 别依赖
time.Now().Unix()校验，用jwt.WithValidator注入自定义时间检查，容忍 ±1.5 秒偏差 - 部署脚本里强制加一行：
ntpdate -s time.windows.com或chronyd -q -
jwt.ParseWithClaims(tokenString, &MyClaims{}, keyFunc)中，keyFunc必须返回非 nil error 才算验证失败；返回nil+ 空 key 会导致 panic
真正难的不是写转发逻辑，而是让网关在后端抖动、网络延迟突增、时钟漂移时仍保持可控行为——超时值、重试条件、时间校准，这三处稍有偏差，就从“可用”变成“不可靠”。
