Go实现API网关核心是流量控制、服务解耦与统一治理，需基于net/http+httputil.NewSingleHostReverseProxy构建基础转发，并集成鉴权、限流、熔断、日志及可观测性能力。
Go 语言实现 API 网关，核心不在于“造轮子”，而在于控制流量、解耦服务、统一治理。直接用 net/http + httputil.NewSingleHostReverseProxy 就能跑通基础路由转发，但生产环境必须考虑鉴权、限流、熔断、日志、可观测性等环节——这些不是可选项，是网关存在的前提。
用 httputil.NewSingleHostReverseProxy 做最简反向代理
这是 Go 标准库提供的轻量级反向代理能力，适合快速验证或低负载场景。它把请求透传给后端服务，不侵入业务逻辑，但也不做任何增强处理。
-
Director函数必须重写，否则Host和URL.Path不会更新，导致后端收不到正确路径或 Host 头 - 默认不转发原始客户端 IP，需手动设置
X-Forwarded-For和X-Real-IP - 超时控制需通过
http.Transport配置，比如IdleConnTimeout和ResponseHeaderTimeout
proxy := httputil.NewSingleHostReverseProxy(&url.URL{Scheme: "http", Host: "127.0.0.1:8081"})
proxy.Director = func(req *http.Request) {
req.Header.Set("X-Forwarded-For", req.RemoteAddr)
req.Host = "api.example.com"
}
用 gorilla/mux 或 chi 实现路由分发与中间件链
标准 http.ServeMux 不支持路径参数和正则匹配，无法满足微服务按 path prefix 或 header 路由的需求。推荐 chi：轻量、无反射、中间件模型清晰，且天然支持嵌套路由和上下文传递。
- 每个 service route 应绑定独立中间件栈（如
authMiddleware、rateLimitMiddleware），避免全局污染 - 路由匹配顺序很重要：
chi是 FIFO，更具体的路径（如/users/{id}）要放在泛化路径（如/users/）之前 - 不要在中间件里直接
return错误响应，应统一用http.Error或自定义 error handler，保证日志可追踪
限流必须基于请求标识（非仅 IP），且区分维度
只按 RemoteAddr 限流在 NAT 或 LB 后完全失效；真实场景需从 Authorization token、X-User-ID 或 API key 中提取唯一标识。建议用 golang.org/x/time/rate + 内存缓存（如 sync.Map）实现 per-user 令牌桶，但要注意：
立即学习“go语言免费学习笔记（深入）”；
- 单机限流无法应对集群扩容，高一致性场景需接入 Redis + Lua（如
redis-cell） - 限流错误码统一返回
429 Too Many Requests，并带Retry-After头 - 避免在限流检查中做耗时操作（如查 DB），token 解析应提前完成并存入
req.Context()
不要在网关层做复杂业务编排或数据聚合
网关的职责是“路由+治理”，不是“BFF”。常见错误包括：在网关里调多个下游服务拼装 JSON、做字段映射、甚至执行简单计算。这会导致：
- 网关变成单点瓶颈，延迟不可控
- 错误传播路径变长，难以定位是网关 bug 还是下游异常
- 升级下游服务时，网关也要同步改，违背微服务松耦合原则
真正需要聚合的场景，应该由前端或独立 BFF 层承担；网关只负责把 /order 转给订单服务，把 /user 转给用户服务，不多一毫，不少一厘。
