动态路由必须脱离硬编码，用外部数据源驱动；gorilla/mux或gin的HandleFunc仅支持启动时静态注册，生产网关需基于sync.Map+原子替换实现热更新，配合监听etcd/Consul/YAML变更，并重写ReverseProxy Director确保真实IP、路径截断与Host透传。
动态路由必须脱离硬编码，用外部数据源驱动
gorilla/mux 或 gin 的 Router.HandleFunc 注册方式只适合启动时静态加载，改一条规则就得重启服务。生产网关必须支持运行时热更新——比如从 etcd、Consul 或本地 YAML 文件监听变更，自动刷新路由表。
关键不是“怎么存路由”，而是“怎么查得快、更新不阻塞请求”。建议用 sync.Map 存 key 为路径前缀（如 /api/user）的路由项，再配一个 goroutine 单独监听配置变化；更新时用原子替换整个 map，避免读写锁竞争。
常见错误是直接在中间件里每次请求都去查 etcd，QPS 上千后 etcd 成瓶颈；或者用普通 map + sync.RWMutex，高并发下读多写少反而被写锁拖慢。
- 路径匹配优先级要明确：精确匹配 > 前缀匹配 > 正则匹配，避免
/api覆盖掉/api/v2 - 路由项至少包含字段：
path、method、backend_url、strip_prefix（是否截断前缀）、weight（灰度用） - 别把 JWT 验证逻辑塞进路由匹配层——它该由独立中间件完成，路由层只负责转发决策
转发必须重写 Director，否则后端收不到真实信息
httputil.NewSingleHostReverseProxy 默认只是把请求原样发过去，后端看到的是网关本机的 RemoteAddr，X-Forwarded-For 为空，Host 是网关地址，URL.Path 也没截断。这些都会让鉴权、日志、重定向全部失效。
立即学习“go语言免费学习笔记（深入）”；
必须显式设置 proxy.Director，且三件事缺一不可：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 重设
req.URL.Scheme和req.URL.Host指向目标后端，否则 302 会跳回网关地址 - 用
strings.TrimPrefix(req.URL.Path, route.StripPrefix)截掉前缀，再赋给req.URL.Path，不手动截就是路径错位 - 加
req.Header.Set("X-Real-IP", clientIP(req))，其中clientIP要优先取X-Forwarded-For最左非私有 IP， fallback 到req.RemoteAddr
漏掉任何一项，下游服务就可能返回 404、拒绝连接或记录错误 IP。别信文档里“默认已处理”的说法——它真没做。
限流和熔断不能靠 context.WithTimeout 单扛
单用 context.WithTimeout 只能防一次卡死，挡不住后端持续抖动或雪崩。你得上真正的熔断器，比如 sony/gobreaker，并按错误类型分类统计：连接拒绝、超时、5xx 响应要分开计数，否则一个 DNS 故障就能把整个熔断器拉满。
限流同理：golang.org/x/time/rate.Limiter 是 per-instance，直接 new 出来塞进 handler 就等于没限。必须按 key（如 req.Header.Get("X-User-ID") 或 IP）查 sync.Map 缓存的 limiter 实例。
- burst 容量别设太大，
rate.NewLimiter(rate.Every(time.Second), 10)允许瞬时 10 次，不是匀速 10 次/秒 - 限流失败要用
limiter.Wait(ctx)，不是time.Sleep——后者会阻塞 goroutine - 熔断器状态变更（如 open → half-open）最好打日志，方便排查为什么某条路由突然不通
别在中间件里自己拼 http.Client，复用 http.Transport 才稳
很多人图省事，在每个转发 handler 里 new 一个 http.Client，结果连接池耗尽、DNS 缓存过期、空闲连接堆积。网关每秒几千请求，http.DefaultClient 的默认 MaxIdleConns=2 会成为性能瓶颈。
正确做法是全局复用一个自定义 http.Transport，重点调这几个参数：
-
MaxIdleConns和MaxIdleConnsPerHost都设为 100+，尤其后端实例多时 -
IdleConnTimeout = 30 * time.Second，太短建连开销大，太长故障节点残留久 - 接管 DNS：用
&net.Resolver{PreferGo: true}+ 自定义dialContext控制 TTL - 转发前清掉 hop-by-hop 头：
req.Header.Del("Connection")、req.Header.Del("Keep-Alive")等，否则某些后端会拒收
最易忽略的是 DNS 缓存——系统默认可能长达 5 分钟，网关发现某个后端挂了，但 DNS 还在返回旧 IP，流量继续打过去直到超时。这个点线上出过多次故障。
