Go无内置API网关，需用net/http+并发控制+中间件实现；http.ServeMux因前缀匹配、无中间件、动态路由缺失及调度粒度粗而不适合生产；应选gorilla/mux或chi.Router，配独立http.Client、context超时、semaphore限流，并严防context丢失。
Go 本身没有“API 网关”内置类型，但用 net/http + 并发控制 + 中间件模式能高效实现轻量级网关；关键不在“并发”本身，而在如何安全复用连接、限流不阻塞、路由不锁竞争。
为什么直接用 http.ServeMux 不适合生产网关
它只支持前缀匹配、无中间件链、不支持动态路由重载，且所有 handler 共享同一 goroutine 调度上下文，一旦某个后端响应慢（如 5s 超时），会拖慢同 Mux 下其他路由的调度感知——不是并发能力不够，而是控制粒度太粗。
实操建议：
- 改用
gorilla/mux或chi.Router，支持正则路径、变量捕获、子路由器隔离 - 每个上游服务应有独立的
*http.Client实例，设置Timeout、Transport.MaxIdleConnsPerHost，避免 DNS 缓存和连接复用冲突 - 禁止在 handler 内直接调用
time.Sleep或同步 I/O，必须用带 cancel 的context.WithTimeout
http.Client 并发调用后端时的常见超时误用
典型错误是只设 Client.Timeout，这会覆盖整个请求生命周期（DNS + dial + TLS + write + read），导致无法区分是后端卡住还是网络抖动。更危险的是：该字段与 context.Context 超时不叠加，后者会被前者静默覆盖。
立即学习“go语言免费学习笔记（深入）”；
正确做法：
- 禁用
Client.Timeout（设为 0），改用ctx, cancel := context.WithTimeout(r.Context(), 800*time.Millisecond) - 为每个后端 client 单独配置
Transport，例如：MaxIdleConns: 100、MaxIdleConnsPerHost: 100、IdleConnTimeout: 30*time.Second - 出错时检查
errors.Is(err, context.DeadlineExceeded)而非字符串匹配"timeout"，避免被底层库错误信息干扰
如何用 semaphore.Weighted 实现每路由并发限制
全局限流（如总 QPS ≤ 1000）容易误伤低频高耗接口；按 path 或 upstream 分组限流才合理。Go 1.21+ 的 golang.org/x/sync/semaphore 是轻量选择，比 channel + mutex 更易推理。
TeemIp是一个免费、开源、基于WEB的IP地址管理（IPAM）工具，提供全面的IP管理功能。它允许您管理IPv4、IPv6和DNS空间：跟踪用户请求，发现和分配IP，管理您的IP计划、子网空间、区域和DNS记录，符合最佳的DDI实践。同时，TeemIp的配置管理数据库（CMDB）允许您管理您的IT库存并将您的配置项（CIs）与它们使用的IP关联起来。项目源代码位于https://github.com/TeemIP
示例逻辑：
// 每个 upstream 对应一个信号量
var upstreamSemas = map[string]*semaphore.Weighted{
"user-service": semaphore.NewWeighted(20),
"order-service": semaphore.NewWeighted(10),
}
func proxyHandler(w http.ResponseWriter, r *http.Request) {
upstream := getUpstreamFromPath(r.URL.Path)
sema, ok := upstreamSemas[upstream]
if !ok {
http.Error(w, "unknown upstream", http.StatusBadGateway)
return
}
// 非阻塞尝试获取许可，超时立即返回
if !sema.TryAcquire(1) {
http.Error(w, "upstream busy", http.StatusTooManyRequests)
return
}
defer sema.Release(1)
// 执行代理逻辑...
}
注意：TryAcquire 不会挂起 goroutine，适合高吞吐场景；若需排队等待，改用 Acquire(ctx, 1) 并确保 ctx 有 timeout。
日志与追踪中容易丢 context 的三个位置
并发网关里最隐蔽的 bug 是 traceID 在 goroutine 切换后丢失，导致日志无法串联、指标聚合失真。
高频丢 context 场景：
- 启动新 goroutine 时直接传
r.Context()—— 必须用ctx := r.Context()显式捕获，再传入闭包 - 调用
log.Printf时没把 traceID 作为字段注入，而依赖全局变量 —— Go 的 global var 在 goroutine 间不隔离 - 使用
http.RoundTrip代理时未将原始 context 注入 request：req = req.Clone(ctx)必不可少
真正难调试的，往往不是并发崩溃，而是某条慢请求悄悄吃掉 20 个信号量许可后不再释放——所以 Release 务必放在 defer，且所有 error path 都要覆盖。
