Go语言写高性能API网关核心是用好goroutine、避免阻塞、分阶段处理；因goroutine仅约2KB开销且由runtime调度，远优于系统线程的1MB+栈内存与高OS调度成本，可使QPS过万、内存压至百MB内。
Go语言写高性能API网关，核心不是堆功能，而是用好goroutine、避免阻塞、把处理流程切成可组合的阶段——这三件事做扎实了，QPS轻松过万，内存压在百MB内。
为什么必须用 goroutine 而不是线程或连接池
HTTP请求是典型的I/O密集型任务：等DNS、等后端响应、等TLS握手。Go的goroutine开销约2KB，调度由runtime接管；而系统线程动辄1MB+，且OS调度成本高。网关每秒处理5000请求时，若用线程模型，光栈内存就吃掉5GB；用goroutine，实际协程数可能只维持在几千个，总内存占用通常
- 错误做法：
http.Server配MaxConnsPerHost硬限流，但没控制goroutine生成节奏，突发流量下协程暴增OOM - 正确做法：在
Handler入口加semaphore（如golang.org/x/sync/semaphore），限制并发处理请求数，再配合超时控制 - 注意：
net/http默认已为每个连接启一个goroutine，你写的中间件逻辑必须是非阻塞的——比如别用time.Sleep做限流，改用rate.Limiter
路由匹配不能靠正则，得用前缀树或哈希分段
线上网关常有上千条路由规则，如果每次请求都遍历切片+正则匹配，CPU会卡在字符串解析上。fiGate和switchboard都用trie（前缀树）存Method+Path，查找时间复杂度O(k)，k是路径长度；kiro-gateway则按Host先哈希分桶，再在桶内查路径，降低单次比对量。
- 常见坑：
path == "/api/v1/users/:id"这种带参数的路由，别手写正则提取，用现成的httprouter或gin.Engine的GET/POST注册方式，它们底层已优化 - 性能敏感场景：禁用
/*通配符路由，它会退化成线性扫描；必须用时，把它放在路由表末尾 - 配置热加载时，重建trie必须原子替换，否则出现
panic: concurrent map read and map write
插件/中间件链必须支持短路和上下文透传
鉴权失败要立刻返回401，不能继续走完限流、日志、转发；熔断器触发后，后续插件应跳过执行。所有插件共享同一个context.Context，并通过ctx.Value()或自定义结构体传递数据（如用户ID、请求ID、上游地址）。
立即学习“go语言免费学习笔记（深入）”；
- 典型错误：某个插件里
ctx, cancel := context.WithTimeout(ctx, 30*time.Second)但忘了defer cancel()，导致context泄漏，goroutine堆积 - 建议结构：每个插件实现
func(http.Handler) http.Handler，用闭包封装逻辑，避免全局状态 - 调试时加
ctx = context.WithValue(ctx, "plugin_trace", append(trace, "auth"))，出错时能快速定位哪个插件panic
真正难的不是写转发逻辑，而是让每个环节的耗时可观察、失败可回滚、配置变更不中断连接——这些细节在压测时才会暴露，但上线前就得想清楚。
