API网关应是可控边界，需精准控制路由、鉴权、限流、超时和可观测性；宜用gin/echo自建轻量网关，结合Consul/Nacos实现动态服务发现与健康实例负载均衡，并注意连接池、URL解析、中间件异常处理、分桶限流、请求体读取、分层超时、DNS超时及SLA对齐等细节。
Go 微服务中，API 网关不该是“另一个服务”，而应是请求入口的**可控边界**——它不处理业务逻辑，但必须精准控制路由、鉴权、限流、超时和可观测性。用 gin 或 echo 自建轻量网关完全可行，没必要一上来就上 Kong 或 Tyk。
用 gin 实现动态路由转发（不硬编码服务地址）
核心是把服务发现结果注入路由表，而非写死 http://user-srv:8081。否则服务扩缩容或重启后，网关会 502。
- 用
consul或nacos做服务注册，启动时拉取user-srv的健康实例列表，缓存到内存（带 TTL 刷新） - 路由匹配后，从实例池选一个（轮询或随机），拼出真实 URL：
http://10.0.1.22:8081/v1/profile - 务必设置
http.Transport的MaxIdleConnsPerHost和IdleConnTimeout，否则长连接堆积导致 fd 耗尽 - 避免在每个请求里重新解析 URL —— 提前用
url.Parse缓存模板，用url.URL的ResolveReference拼接路径
gorilla/handlers 做中间件组合时的坑
常见错误是把鉴权、限流、日志等中间件全堆在 Use 链里，结果某个中间件 panic 导致后续全跳过，且错误难以定位。
- 用
handlers.CompressHandler前先检查Accept-Encoding，否则对不支持 gzip 的客户端返回乱码 -
handlers.ProxyHeaders只信任内网 IP（如10.0.0.0/8），否则 X-Forwarded-For 可被伪造 - 自定义限流中间件别用全局计数器（如
sync.Map存 key），应基于golang.org/x/time/rate.Limiter+ 用户 ID 或 API 路径做分桶 - 日志中间件里别直接打印
r.Body—— 它是一次性 reader，后续业务 handler 会读不到数据；需用httputil.DumpRequest并设noBody: false
超时控制必须分层：网关层 ≠ 后端服务层
网关的 context.WithTimeout 只控制“从收到请求到拿到响应”的总耗时，不能替代后端自身的超时设置。
立即学习“go语言免费学习笔记（深入）”；
- 对外暴露的 API 超时设为 8s，但转发到
order-srv时，应额外加 2s buffer（即 10s），防止因网关调度延迟误杀 - 用
http.NewRequestWithContext传入子 context，而不是改原始req.Context()—— 后者会影响其他中间件 - 若后端返回 499（client closed request），网关要主动 cancel 对应的后端请求，避免 goroutine 泄漏
- 别忽略 DNS 解析超时：用
&net.Dialer{Timeout: 2 * time.Second}替代默认 dialer
真正的难点不在代码量，而在网关行为与后端服务 SLA 的对齐——比如限流窗口怎么和下游的 Redis 计数器对齐，JWT 公钥轮换时如何平滑过渡，以及当 Consul 失联时该 fallback 到本地缓存还是直接 503。这些细节没日志、没指标、没混沌测试，上线后只会以“偶发超时”形式出现。
