选 gin，因其默认支持路径参数提取、中间件链可控、错误处理不隐式 panic，适合网关统一鉴权、限流、日志等关键需求。
用 gorilla/mux 还是 gin 做网关路由层？
直接说结论：选 gin，不是因为它“更流行”，而是它默认支持路径参数提取、中间件链可控、错误处理不隐式 panic——这对网关这种需要统一鉴权、限流、日志的入口层太关键了。
常见错误是拿 gorilla/mux 当 Web 框架用：它路由强大，但中间件模型松散，http.Handler 链容易漏掉 recover，一出错整个网关挂掉；而 gin 的 Use() 和 Abort() 能明确控制流程，比如鉴权失败直接 c.AbortWithStatus(401)，后续中间件不执行。
-
gin默认禁用debug模式（GIN_MODE=release），上线不手抖也能安全 -
gorilla/mux的Vars(c.Request)返回 map，类型不安全；gin的c.Param("id")是 string，配合strconv.Atoi更直觉 - 如果已有大量
net/http工具函数（比如自定义http.RoundTripper），gin也能无缝接入，它的c.Writer就是http.ResponseWriter
http.RoundTripper 自定义超时与重试必须改哪些字段？
网关转发请求不是简单 http.DefaultTransport 一贴了事。默认 Transport 对后端服务波动毫无抵抗力：DNS 缓存过长、连接复用卡死、单次请求超时固定在 30 秒——这些都会让网关变成故障放大器。
关键改三项：Timeout 控制整次请求生命周期；IdleConnTimeout 防止后端重启后连接僵死；MaxIdleConnsPerHost 避免文件描述符耗尽。别碰 TLSClientConfig.InsecureSkipVerify，那是测试用的，上线必须删。
立即学习“go语言免费学习笔记（深入）”；
-
Timeout设为 5–8 秒（比下游服务 P99 高 2 秒即可），太短误杀，太长拖垮并发 -
IdleConnTimeout推荐 30 秒，和大多数后端 HTTP server 的 keep-alive timeout 对齐 - 重试逻辑不要塞进 Transport，用独立中间件做：只对
502/503/504和连接级错误（net.ErrClosed,context.DeadlineExceeded）重试 1 次，且带 jitter
JWT 鉴权中间件里 ParseWithClaims 为什么总报 token is expired？
不是 token 真过期了，八成是网关服务器时间没同步。JWT 的 exp 字段是绝对时间戳（Unix 秒），误差 >1 秒就会被 jwt-go 拒绝——而 systemd-timesyncd 默认 5 分钟同步一次，压测时完全不够用。
别依赖 time.Now().Unix() 做校验，用 jwt.WithValidator 注入自定义时间检查逻辑，容忍 ±1.5 秒偏差。同时强制加一行 ntpdate -s time.windows.com 到部署脚本里。
- 用
jwt.ParseWithClaims(tokenString, &MyClaims{}, keyFunc)时，keyFunc必须返回非 nil error 才算验证失败，返回nil+ 空 key 会导致 panic - 别在 claims 结构体里嵌
jwt.StandardClaims后又手动赋值ExpiresAt，jwt-gov4+ 已废弃该字段，要用RegisteredClaims - 测试时用
time.Now().Add(-2 * time.Hour).Unix()生成过期 token，别用固定数字，避免时区陷阱
gRPC-Gateway 与 REST 接口共存时，runtime.NewServeMux 的注册顺序影响什么？
顺序错了，/healthz 这种简单 GET 接口可能被 gRPC-Gateway 的通配路由吞掉，返回 404 或更糟的 500（因为 proto 反射失败）。gRPC-Gateway 的 mux 是贪婪匹配，必须把 REST 专用路由（如健康检查、指标暴露）注册在 runtime.NewServeMux 之前。
另外，runtime.NewServeMux 默认不处理 OPTIONS，CORS 要自己加中间件；它也不支持 multipart/form-data，文件上传得绕过 gateway 直连后端。
- 先注册
http.HandleFunc("/healthz", healthHandler)，再gwMux := runtime.NewServeMux()，最后gwMux.HandlePath("POST", "/v1/{name}", ...) - proto 文件里每个 RPC 方法必须加
google.api.httpoption，否则runtime.NewServeMux根本不注册该路由 - 如果后端是 gRPC-Web，前端用
grpc-webclient，网关必须开--enable-grpc-web参数，且反向代理要透传content-type: application/grpc-web+proto
真正难的从来不是写转发逻辑，而是时间同步、连接池水位、错误传播边界这些看不见的线。上线前盯三件事：ntpq -p 输出是否正常、lsof -i :8080 | wc -l 是否稳定、curl -I http://localhost:8080/healthz 返回是不是 200——别的都往后排。
