Go语言适合自研API网关，但仅适用于强定制路由、低延迟注入或统一Go运维栈等特定场景；若仅需简单转发与JWT验证，Nginx更稳；生产中应组合httputil.ReverseProxy与chi中间件，而非直接用gorilla/mux或chi当核心网关。
Go语言适合自研API网关，但不等于“所有场景都该自己写”。是否选型Go网关，取决于你是否真的需要它解决的那几个具体问题——比如强定制路由逻辑、低延迟链路注入、或统一Go技术栈运维。
什么时候该用Go写网关，而不是直接配Nginx
判断依据不是语言偏好，而是业务约束是否真实存在：
- 需要在请求头里动态注入
X-Trace-ID并基于User-ID哈希做灰度路由——Nginx的Lua插件能做，但调试和上线流程重，Go里改一行if r.Header.Get("X-User-ID") != ""就能测 - 上游服务要求gRPC over HTTP/2透传，且需在网关层校验TLS双向证书后提取SPIFFE ID——
net/http+grpc-go组合比OpenResty里混搭gRPC-Web代理更可控 - 团队已用
prometheus/client_golang统一打标所有服务指标，而Kong的Prometheus插件无法按路径维度打service_name标签——自己写中间件，metrics.IncByPath(r.URL.Path)即可 - 只是转发几个REST接口+加JWT验证？
nginx.conf里三行proxy_pass+auth_request更快更稳；硬套Go反而要自己兜http.Transport的MaxIdleConnsPerHost、IdleConnTimeout、重试退避逻辑
别直接用gorilla/mux或chi当生产网关核心
它们是路由器，不是反向代理。常见翻车点：
-
chi默认不管理下游连接池——高并发时too many open files错误频发，必须手动配置http.Transport并复用 - 上游返回
502 Bad Gateway时，chi只抛http.Error，无法区分是DNS失败、连接拒绝还是读超时，得自己解析url.Error的Err字段 - 没有原生负载均衡策略——轮询要自己维护
[]*url.URL列表，最少连接数还得加原子计数器，httputil.NewSingleHostReverseProxy只支持单目标 - 更务实的做法：
net/http/httputil.NewSingleHostReverseProxy做代理基座，再用chi做前置中间件（鉴权、限流、日志），二者职责清晰，代码量少且易测试
httputil.ReverseProxy必须重写的几个方法
默认行为在生产环境几乎不可用，至少覆盖这三处：
-
Director函数：必须重写，否则Host头不透传，后端服务拿不到原始域名；还要手动设置X-Real-IP和X-Forwarded-For，不能依赖req.RemoteAddr（可能被CDN污染） -
Transport字段：必须指定MaxIdleConns、MaxIdleConnsPerHost、IdleConnTimeout，否则连接泄漏；若需mTLS，还得注入TLSClientConfig -
ErrorHandler函数：默认直接http.Error返回500，掩盖真实错误；应根据err类型分类处理——net.OpError记为连接失败，net/url.Error记为DNS异常，再统一返回结构化JSON
JWT验证为什么不宜放在网关层做完整校验
性能和职责边界问题：
- 完整JWT解析（含签名验签、过期检查、scope校验）耗CPU，网关应只做轻量可信头注入——比如用
jwt.Parse验证签名和基础字段，成功后注入X-Auth-User-ID、X-Auth-Roles等头，把细粒度权限判定留给业务服务 - 密钥轮换时，网关需同步更新
SigningKey，而业务服务可能用不同密钥策略（如按租户分密钥）——网关只负责“可信身份声明”，不承担RBAC逻辑 - 若用
github.com/golang-jwt/jwt/v5，注意ParseWithClaims默认不校验exp，必须显式传入jwt.WithValidatedClaims，否则有安全风险
真正难的不是写一个能跑的Go网关，而是决定哪些逻辑必须放网关、哪些必须下沉——边界模糊时，先看监控指标：如果gateway_latency_p99超过15ms，就要警惕是不是在网关里做了不该做的JSON解析或远程调用。
