Go语言可自研轻量高性能API网关，适用强定制、低延迟、Go生态统一场景；不推荐用gorilla/mux或chi直接当生产网关，应组合httputil.ReverseProxy与chi中间件；需手动处理真实IP透传、独立超时、响应头重写；JWT验证宜下沉至业务层，网关仅做基础鉴权与可信头注入。
Go 语言本身不提供现成的 API 网关，但用 net/http + 中间件模式 + 路由分发，能写出轻量、可控、高性能的自定义网关——关键不是“有没有”，而是“要不要自己写”。
什么时候该用 Go 写网关，而不是直接上 Kong/Nginx/Tyk
你真正需要自研网关，通常只出现在这几个场景：
- 内部系统对请求链路有强定制需求，比如必须在网关层注入特定 trace header、做灰度路由决策（按用户 ID 哈希分流）、或调用内部鉴权服务并缓存结果
- 现有网关无法满足低延迟要求（例如 P99
- 团队已深度使用 Go 生态，运维链路统一（日志、metrics、配置中心都基于 Go 工具链），引入新语言组件会增加维护成本
如果只是想加个限流、JWT 验证、转发到几个 REST 服务，nginx 配几行 proxy_pass 更快更稳；强行用 Go 写反而多出一堆连接池、超时、重试逻辑要自己兜底。
gorilla/mux 或 chi 能不能直接当网关用
能跑通，但不推荐直接当生产网关核心。它们是通用 HTTP 路由器，不是为反向代理设计的：
立即学习“go语言免费学习笔记（深入）”；
- 没有内置的连接复用管理：
http.Transport的MaxIdleConnsPerHost、IdleConnTimeout必须手动配，否则高并发下容易耗尽文件描述符 - 错误处理粒度粗：比如上游返回
502 Bad Gateway，你得自己解析http.RoundTrip错误类型，区分是 DNS 失败、连接拒绝还是读超时 - 不支持原生的负载均衡策略：轮询、权重、最少连接数这些得自己实现
http.RoundTripper或封装url.URL列表
更务实的做法是用 net/http/httputil.NewSingleHostReverseProxy 做基础代理，再用 chi 做前置路由和中间件（鉴权、日志、限流），二者组合比硬套一个路由器更清晰。
如何让 ReverseProxy 支持真实客户端 IP 和超时控制
httputil.NewSingleHostReverseProxy 默认不透传客户端 IP，且所有请求共用一个全局超时，这两点线上必改：
- 透传真实 IP：在
Director函数里显式设置req.Header.Set("X-Real-IP", clientIP)，其中clientIP从http.Request.RemoteAddr解析（注意处理X-Forwarded-For多级代理情况） - 每个 upstream 独立超时：不要动
http.Server.ReadTimeout，而是在Director后、proxy.ServeHTTP前，用context.WithTimeout包裹req.Context()，再通过req = req.WithContext(ctx)注入 - 必须重写
ModifyResponse：否则上游返回的Set-Cookie、Location等 header 可能含内部地址，需替换为公网域名
示例关键片段：
proxy := httputil.NewSingleHostReverseProxy(upstreamURL)
proxy.Director = func(req *http.Request) {
req.Header.Set("X-Real-IP", getRealIP(req))
req.URL.Scheme = upstreamURL.Scheme
req.URL.Host = upstreamURL.Host
}
proxy.ModifyResponse = func(resp *http.Response) error {
if loc := resp.Header.Get("Location"); loc != "" {
resp.Header.Set("Location", strings.ReplaceAll(loc, "http://internal", "https://api.example.com"))
}
return nil
}
为什么别急着加 JWT 验证中间件到网关层
看似合理，实则容易埋坑：
- JWT 解析和验签是 CPU 密集操作，网关是流量入口，高并发下可能成为瓶颈；不如让业务服务自己验证，网关只做路由和基础鉴权（如 API Key）
- 密钥轮换难：网关要同步更新所有实例的
public key，而业务服务可各自走配置中心热加载 - 细粒度权限控制失焦：JWT 里的
scope或permissions字段，往往需要结合业务上下文判断（比如 “能删订单” 还要看订单归属），网关层无法安全决策
更稳妥的分层是：网关验证 token 是否有效（签名、过期）、提取 sub 和 iss，注入 X-User-ID 等可信头，把权限判断留给下游服务。
真正难的从来不是怎么转发请求，而是怎么让每次转发都可观察、可回溯、可降级——比如上游挂了，你是直接 502，还是切到本地缓存，或是返回预设的兜底 JSON？这些逻辑没标准答案，得贴着你的业务 SLA 来写。
