Go服务网关核心是权衡是否自研：多数场景gin+gorilla/mux+httputil反向代理已足够；需自研时聚焦流量治理诉求。httputil.NewSingleHostReverseProxy为轻量起点，需正确配置Director、ModifyResponse及Transport参数，并按上游隔离连接池。
Go 语言实现服务网关，核心不是“能不能做”，而是“要不要自己从零造轮子”。绝大多数业务场景下，gin + gorilla/mux + 手写路由分发 + net/http/httputil 反向代理已足够；真正需要自研网关的，通常是已有流量治理诉求（如熔断、限流、鉴权链路统一）但又受限于现有方案扩展性或性能。
用 net/http/httputil.NewSingleHostReverseProxy 快速启动反向代理
这是 Go 原生最轻量、最可控的代理起点。它不封装业务逻辑，只负责转发请求/响应，适合做网关底层转发层。
常见错误：直接传入带路径的 url.URL（如 http://svc-a:8080/api），导致后端收到重复路径（/api/api/xxx）。正确做法是只传根地址（http://svc-a:8080），再手动重写 req.URL.Path 和 req.URL.RawPath。
实操建议：
HISUI 前端框架基础开发指南。HISUI 是基于 easyui 二次开发的 jQuery UI 组件库，专为医疗信息系统设计。当涉及 HISUI 组件开发、jQuery easyui 表格/表单/布局/窗口、医疗系统前端页面编写时使用此 skill。 涵盖 40 个组件的官方文档参考，支持声明式与编程式两种初始化方式，提供 $cm/$m 数据访问方法。
立即学习“go语言免费学习笔记（深入）”；
- 用
Director函数修改req：设置req.Host = upstream.Host、清除req.Header["X-Forwarded-For"]后追加客户端 IP - 必须覆盖
ModifyResponse：否则后端返回 302 重定向时 Location 头不会被改写，导致跳转到内网地址 - 若需透传原始 Host，别动
req.Host，而是在Director中显式设置req.Header.Set("Host", upstream.Host)
在 gin 中注入网关中间件做统一鉴权与路由匹配
gin 不是网关框架，但它的中间件机制和 gin.RouterGroup 路由树，恰好适合承载网关的“前置控制”逻辑——比如 JWT 解析、服务发现查询、灰度标签提取。
使用场景：你不想把所有路由硬编码进 gin.Engine，而是希望根据请求路径（如 /user/v1/profile）动态查注册中心拿到真实上游地址。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在
gin.HandlerFunc中解析c.Request.URL.Path，调用服务发现 client（如etcd或nacosSDK）获取实例列表 - 避免在中间件里做耗时操作（如每次请求都查一次 etcd）；应结合本地缓存（
sync.Map或lru包）+ TTL 刷新 - 路由匹配优先级要明确：API Path 匹配 > 请求头匹配（如
X-Env: staging） > 权重随机选择；顺序错会导致灰度失效
用 gobreaker 实现服务熔断，而非简单超时
网关层超时（context.WithTimeout）只能防止自身阻塞，无法感知下游是否已不可用。熔断是主动降级，避免雪崩。
性能影响：默认 gobreaker.Settings 的 Interval 是 60 秒，意味着每分钟才重试一次失败服务；生产环境建议设为 10~30 秒，并搭配 RequestVolumeThreshold（如 100）和 ErrorThresholdPercentage（如 60）组合判断。
容易踩的坑：
- 熔断器实例不能全局复用——不同上游服务必须用独立
*gobreaker.CircuitBreaker，否则一个服务挂了会拖垮全部 - 不要在
cb.Execute里直接传入http.Client.Do调用；应包装成函数闭包，确保错误能被gobreaker正确识别（它只捕获非nilerror） - 开启熔断后，务必提供 fallback 响应（如返回 503 + JSON 提示），否则前端会收空响应或连接关闭
别忽略 http.Transport 的连接复用与超时配置
网关作为 HTTP 客户端，http.DefaultTransport 的默认参数极不适合高并发代理：最大空闲连接数仅 100，无连接空闲超时，DNS 缓存永久有效。
关键参数差异：
-
MaxIdleConns和MaxIdleConnsPerHost建议设为 1000+，尤其当后端服务多于 10 个时 -
IdleConnTimeout设为 30s，避免 TIME_WAIT 过多；TLSHandshakeTimeout设为 5s 防止 TLS 握手卡死 - 必须设置
GetConfig的Resolver为自定义 DNS cache（如dnscache包），否则每次请求都走系统 DNS，延迟飙升且易受 DNS 故障影响
复杂点在于：这些 Transport 需按上游服务维度隔离（例如支付服务用一套连接池，用户服务用另一套），否则长尾请求会抢占短平快接口的连接资源。这点常被忽略，直到压测时出现大量 net/http: request canceled (Client.Timeout exceeded while awaiting headers) 才去排查。
