结论：用 Gin 做轻量级 API 网关合理，但必须禁用 gin.Default()、手动配置中间件、重写 Transport 超时与连接参数、注入自定义 JWT 时间容错及分布式限流——否则易成故障放大器。
直接说结论：用 Gin 做轻量级 API 网关是合理选择，但必须绕开默认配置、禁用调试、重写转发逻辑——否则上线即成故障放大器。
为什么 gin.Default() 不能直接用于网关
gin.Default() 自带 gin.Logger() 和 gin.Recovery()，看起来省事，实则埋雷：
- Logger 默认写到
os.Stdout，高并发下 I/O 成瓶颈，P99 延迟翻倍 - Recovery 捕获 panic 后只返回 500，不记录原始错误上下文，线上定位难
- 它默认启用
GIN_MODE=debug，会暴露路由树、中间件栈，内网都算风险 - 没做任何超时控制，下游服务卡死，网关连接池迅速耗尽
正确做法是用 gin.New()，手动加你真正需要的中间件：
router := gin.New() router.Use(gin.RecoveryWithWriter(zap.L().Desugar().Writer)) // 换成 Zap 日志 router.Use(requestID()) // 注入 trace_id router.Use(timeoutMiddleware(8 * time.Second)) // 全局超时
反向代理转发必须重写 Transport
直接用 httputil.NewSingleHostReverseProxy 转发，不出三天必出问题。默认 http.Transport 的三个字段不改，等于把网关当裸奔：
立即学习“go语言免费学习笔记（深入）”；
-
Timeout：默认 0（无限），应设为5–8s（比下游 P99 高 2s 即可） -
IdleConnTimeout：默认 0，需设为30s，否则后端重启后长连接僵死 -
MaxIdleConnsPerHost：默认 100，建议调至500+，避免 fd 耗尽
别碰 TLSClientConfig.InsecureSkipVerify，测试可以，上线删掉——这是证书校验绕过，不是“开发便利”。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
JWT 鉴权中间件里 token is expired 总报错
八成不是 token 真过期，而是服务器时间不同步。JWT 的 exp 是 Unix 时间戳，jwt-go 默认容错仅 ±1 秒：
- systemd-timesyncd 默认 5 分钟同步一次，压测时误差轻松超 2 秒
-
jwt.ParseWithClaims的keyFunc若返回nil+ 空 key，会 panic，不是 error - 必须用
jwt.WithValidator注入自定义时间检查，容忍 ±1.5 秒偏差
部署脚本里强制加一行：ntpdate -s time.windows.com 或用 chrony 替代。
限流/熔断别自己从零实现
单机 golang.org/x/time/rate 在网关场景基本无效：
- 各实例令牌桶独立，分布式流量下限流形同虚设
- 熔断依赖全局错误率统计，进程内存无法反映集群健康度
- 密钥轮换、黑名单管理、OAuth2 授权码流程，自己写半年也难闭环
生产环境该用 Redis + Lua 做原子限流，或接入 Istio/Envoy；鉴权走 Keycloak 或 Auth0，别硬扛。
最易被忽略的一点：网关不是“转发完就完事”的胶水层，它的每个中间件都要能 abort 流程、能透传上下文、能打标 trace_id——否则日志散落、链路断裂、扩容后问题更难复现。
