Gin 中实现反向代理应复用 net/http/httputil.NewSingleHostReverseProxy，通过自定义 Director 重写 req.URL 和 req.Host，配合 Gin 路由匹配（如 /api/:service/*path）与中间件（鉴权、限流、日志）实现网关能力，严禁业务逻辑侵入代理流程。
怎么用 Gin 做反向代理而不是 Web 服务
直接写 r.POST("/v1/chat", handler) 是错的——网关不是业务服务，不该自己处理请求逻辑，而是把请求原样或稍作改写后转发出去。
正确做法是复用 Go 标准库的 httputil.NewSingleHostReverseProxy，再用 Gin 的中间件能力做前置控制（鉴权、限流、日志），最后交由 ReverseProxy 执行实际转发。
-
Gin路由只负责匹配和提取参数，比如r.Any("/api/:service/*path", proxyHandler)，其中:service决定目标上游，*path保留完整路径 -
Director函数必须重写req.URL和req.Host，否则后端收不到原始路径或 Host 头 - 别在
Director里做耗时操作（如查 Redis），它在每次请求都同步执行，会拖慢整个链路
http.Transport 配置不改，网关迟早挂
用默认 http.DefaultTransport 转发，不出三天就会遇到连接堆积、DNS 缓存失效、超时卡死等问题。这不是理论风险，是生产环境高频故障点。
必须显式配置自定义 Transport，关键三项不能省：
立即学习“go语言免费学习笔记（深入）”；
-
Timeout设为5–8s：比下游 P99 延迟高 2 秒即可，设成 30s 会导致并发线程被长期占着 -
IdleConnTimeout设为30s：和大多数后端 HTTP server 的 keep-alive timeout 对齐，避免僵死连接 -
MaxIdleConnsPerHost至少设为100：防止高并发下文件描述符耗尽，MaxIdleConns建议1000
顺手禁掉 TLSClientConfig.InsecureSkipVerify: true ——上线前删掉，这是测试残留，不是“临时方案”。
中间件顺序错了，c.Abort() 就没意义
Gin 中间件是链式执行，顺序决定控制流走向。典型错误是把日志中间件放最前，结果鉴权失败了还记了一条“成功日志”。
推荐顺序（从外到内）：
- 恢复中间件（
gin.Recovery()）——兜底 panic，必须最外层 - 限流中间件（
RateLimiter）——在鉴权前拦住恶意流量，省得浪费 JWT 解析开销 - 鉴权中间件（JWT 或 API Key）——失败时调
c.AbortWithStatus(401)，后续中间件不会执行 - 日志中间件（异步写入）——只记录通过鉴权的请求，且用 goroutine + channel 缓冲，不阻塞主流程
注意：c.Abort() 只终止当前中间件链，不影响其他路由；c.AbortWithStatus() 会立即返回响应并中断整个请求生命周期。
动态路由注册别硬编码，router.Handle 也不够用
线上网关要支持运行时增删路由（比如新增一个模型服务），靠重启加载 YAML 不现实。硬编码 r.GET("/v1/gpt-4", ...) 更不可维护。
可行方案是封装一个路由管理器：
- 用
sync.RWMutex保护路由映射表，读多写少场景下性能足够 - 每条路由规则含
Path、Method、Upstream、Filters字段，支持正则或前缀匹配 - 注册新路由时，调用
router.Handle(method, path, proxyHandler)，而非重新router.GET - 避免用
gorilla/mux替代——它的Vars()返回map[string]string，类型不安全，且中间件链难控制
真正麻烦的不是加路由，而是旧路由下线时如何优雅清空连接、等待正在处理的请求完成——这需要配合 http.Server.Shutdown() 和 context 超时控制。
