路由匹配慢应换 httprouter（radix tree、零分配）或 chi（模块化、中间件友好），避免 net/http servemux 的线性遍历和正则硬编码；前者性能更高，后者更易扩展。
路由匹配慢？别硬写正则，用 httprouter 或 chi
Go 标准库 net/http 的 ServeMux 只支持前缀匹配，无法处理 /api/users/:id 这类带参数的路径，强行用字符串切分或正则会导致每次请求都触发全量遍历或编译开销。生产环境必须换更高效的路由库。
推荐两个主流选择：httprouter（轻量、零内存分配、Radix Tree 实现）和 chi（模块化、中间件友好、支持通配符和子路由）。前者性能更高，后者更易扩展。
-
httprouter路由注册示例：r.GET("/api/users/:id", userHandler)，匹配时直接查树，无反射、无闭包捕获 -
chi支持嵌套中间件：r.Route("/api", func(r chi.Router) { r.Use(authMiddleware); r.Get("/users/{id}", userHandler) }) - 避免在路由里做业务判断——比如根据
Header动态选后端，应交给中间件或反向代理层，否则路由表膨胀且不可缓存
反向代理卡顿？别直接 new SingleHostReverseProxy
httputil.NewSingleHostReverseProxy 是个便利封装，但默认配置下极易出问题：连接不复用、超时不控制、错误不重试、header 透传不安全。高并发下会迅速耗尽文件描述符或卡在阻塞读写上。
必须显式定制 Director 和 Transport：
- 设置
Director修改req.URL，注意清除原始Host头防止 Host 注入：req.Host = u.Host; req.URL.Scheme = u.Scheme; req.URL.Host = u.Host - 自定义
http.Transport：启用MaxIdleConns/MaxIdleConnsPerHost（建议设为 100+），禁用IdleConnTimeout（设为 30s），并配置TLSClientConfig避免证书校验失败 - 务必替换
ProxyErrorHandler，否则 5xx 错误会直接返回空响应而不是透传后端状态码
限流器总失效？rate.Limiter 不是万能解药
golang.org/x/time/rate.Limiter 适合单实例限流，但在多实例网关或需跨节点统计的场景下，它只作用于当前进程 goroutine，完全无法应对分布式流量。直接套用会导致限流形同虚设。
真实生产中要分三层处理：
- 接入层本地限流：用
rate.Limiter做快速拒绝（如每秒 1000 请求），防突发打垮本机 - 服务级全局限流：集成 Redis + Lua 脚本实现原子计数（例如基于用户 ID 或 API Key 的滑动窗口）
- 后端感知限流：在反向代理前注入
X-RateLimit-Remaining等头，让下游服务也能参与决策 - 注意令牌桶重置逻辑——
limiter.ReserveN返回的time.Time是“最早可执行时间”，不是“等待时长”，别错当成 sleep 时间
JWT 认证后怎么把用户信息传给下游？别往 context 里塞 map
很多实现把解析后的 JWT claims 直接塞进 context.WithValue，然后在 handler 里强转 map[string]interface{}。这既破坏类型安全，又让下游服务必须依赖网关的解析逻辑，耦合严重。
正确做法是标准化透传字段：
- 统一提取关键字段（如
sub、scope、exp），转成结构体后序列化为 header，例如X-User-ID: 123、X-User-Scopes: "read:order,write:user" - 若下游是 gRPC 服务，可在 metadata 中注入：
md := metadata.Pairs("user_id", userID, "scopes", scopes) - 永远不要透传原始 JWT token——签名密钥轮换或算法变更时，下游无法适配；也不要透传敏感字段如
password_hash
动态路由、健康检查、可观测性埋点这些模块看似独立，其实都依赖路由匹配结果和上下文传递的稳定性。一个没清理的 context.Value 或一个没关闭的 http.Response.Body，都可能在高 QPS 下演变成内存泄漏或 fd 耗尽。网关不是胶水代码，它是整个微服务流量的咽喉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
