Go API网关核心是“要不要自研”而非“能不能做”，中等规模用gorilla/mux+net/http+中间件已足够；需强定制时才考虑自研，关键在路由、鉴权、限流、代理的正确实现与可观测性保障。
Go 语言构建的 API 网关，核心不是“能不能做”，而是“要不要自己造”。绝大多数场景下，gorilla/mux + net/http + 中间件组合已足够支撑中等规模微服务流量调度；真正需要自研网关的，往往是已有统一认证、灰度路由、熔断降级等强定制需求，且现有开源方案（如 Kong、Tyk、Traefik）插件机制或扩展成本过高。
用 http.ServeMux 做基础路由分发，但别只靠它
http.ServeMux 是 Go 标准库最轻量的路由分发器，适合做入口层兜底或静态路径映射。但它不支持路径参数提取、正则匹配、中间件链式调用——这些得自己补。
- 若需
/api/v1/users/{id}这类动态路径，直接用gorilla/mux替代，它返回的是http.Handler，可无缝接入标准http.Server - 避免在
ServeMux上注册大量HandleFunc，每次请求都要线性遍历所有 pattern；高频路径建议预编译为 map 查找（例如将/auth/、/order/映射到后端 service 实例） - 不要把鉴权逻辑写进
ServeMux的 handler 函数里——它没上下文传递能力；改用中间件包装，比如authMiddleware(http.Handler)返回新Handler
流量控制必须基于 context.Context 和限流器实例隔离
全局共享一个 rate.Limiter 会导致不同服务之间互相挤占配额；而每个请求都 new 一个又失去意义。正确做法是按「服务名 + 接口路径」维度构造限流器 key，并复用 golang.org/x/time/rate 实例。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 限流器应缓存在
sync.Map或带 TTL 的内存 cache（如groupcache）中，key 形如"user-service:/v1/profile" - 务必在
http.Request.Context()中注入超时和取消信号：ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second)，并在转发前传入下游 client - 注意
rate.Limit的单位是「每秒请求数」，不是「每分钟」；QPS=100 写成rate.Every(10 * time.Millisecond)，别错用time.Second / 100
反向代理转发时，httputil.NewSingleHostReverseProxy 的坑要手动填
Go 标准库的 httputil.NewSingleHostReverseProxy 能快速实现基础转发，但它默认不修改 Host 头、不重写 Location 响应头、也不透传客户端真实 IP —— 这些都得自己 patch。
立即学习“go语言免费学习笔记（深入）”；
- 必须覆盖
Director字段：设置req.Host = upstream.Host，并用req.Header.Set("X-Real-IP", getClientIP(r))补充来源信息 - 响应头中的
Location（如 302 跳转）需用modifyResponse回调重写为公网域名，否则前端会跳到内网地址 - 不要直接
proxy.ServeHTTP(w, r)；应在 defer 中调用cancel()并检查ctx.Err()，防止上游 hang 住导致连接泄漏
真正的难点不在代码行数，而在如何让每个请求的生命周期（认证→限流→路由→转发→日志→指标）都保持可观测、可配置、可回滚。比如限流策略变更后，旧连接还在跑，新策略怎么平滑生效？这类问题没有银弹，只能靠 context 取消、原子变量切换策略实例、以及足够细粒度的 metrics 打点来兜底。
