默认 http.ServeMux 在高并发下易成瓶颈，因其路由匹配为 O(n) 顺序遍历、不支持 Trie 或方法区分，建议换用 chi 等高性能路由器并优化 transport 连接池。
为什么默认的 http.ServeMux 在高并发下容易成为瓶颈
Go 的 http.ServeMux 本身是线程安全的，但它的路由匹配是顺序遍历，时间复杂度为 O(n)。当注册了几十个甚至上百个路由（尤其含大量带变量路径如 /api/v1/users/:id），每次请求都要从头比对，CPU 缓存不友好，高频请求下会明显拖慢 net/http 的整体吞吐。
更关键的是：它不支持前缀树（Trie）或正则预编译优化，也无法区分 GET 和 POST 同路径的不同 handler —— 这意味着你得在 handler 内部做方法判断，徒增分支开销。
- 避免在
http.ServeMux中注册超过 20 条手工路由；超出时务必换用专用路由器 - 不要用
strings.HasPrefix(r.URL.Path, "/static/")这类运行时字符串判断做静态路由分发 —— 它比http.StripPrefix+ 子服务更慢且易出错 - 若必须兼容旧代码，可用
http.NewServeMux()配合sync.RWMutex手动缓存路径哈希映射，但收益有限，不如直接切到gorilla/mux或chi
用 chi 替代默认 mux 并启用路由预编译
chi 是目前 Go 生态中轻量、无反射、支持中间件链和上下文传递最成熟的路由器。它的核心优势在于：所有路由在 chi.NewRouter() 初始化后即构建为静态前缀树，匹配为 O(log n)，且自动按 HTTP 方法分桶。
它还内置了 chi.URLParam、chi.RouteContext 等零分配访问方式，避免反复解析 URL 路径。
立即学习“go语言免费学习笔记（深入）”；
package mainimport ( "net/http" "github.com/go-chi/chi/v5" "github.com/go-chi/chi/v5/middleware" )
func main() { r := chi.NewRouter() r.Use(middleware.Recoverer) r.Use(middleware.RealIP)
// ✅ 路由在启动时即固化，无运行时反射或正则编译 r.Get("/api/users", listUsers) r.Get("/api/users/{id}", getUser) r.Post("/api/users", createUser) http.ListenAndServe(":8080", r)}
func getUser(w http.ResponseWriter, r *http.Request) { id := chi.URLParam(r, "id") // 零分配，直接取已解析值 w.Header().Set("Content-Type", "application/json") w.Write([]byte(
{"id":"+ id +"})) }
- 禁用
chi.ServerBaseContext（除非真需要全局 context 注入），它会增加每次请求的 interface{} 分配 - 避免在
chi.Route内嵌套过深（>5 层），会导致栈帧膨胀；用r.Group()代替多层r.Route() - 不要在 handler 中调用
r.Context().Value()多次 —— 改为一次取出并局部变量缓存
控制连接生命周期：复用 http.Transport 与限制 idle 连接
服务端作为 HTTP 客户端发起下游调用（如调第三方 API、内部微服务）时，若每次请求都新建 http.Client，会快速耗尽文件描述符，并触发 TCP TIME_WAIT 泛滥。根本解法是复用 http.Transport 实例，并精细控制连接池。
默认 transport 的 MaxIdleConns 和 MaxIdleConnsPerHost 均为 100，但在高 QPS 场景下常需调大；而 IdleConnTimeout 过长（默认 30s）会导致连接空闲堆积，过短又引发频繁重连。
- 全局只创建一个
&http.Client{Transport: ...}实例，注入到 handler 或依赖容器中 - 将
MaxIdleConnsPerHost设为 200–500（视下游机器数和单机 QPS 调整），避免跨 host 抢占 -
IdleConnTimeout推荐设为 15–25s，配合下游服务的 keepalive timeout（通常 Nginx 默认 75s，可略小于它） - 务必设置
Response.Body.Close()—— 即使你不读 body，否则连接无法归还给池
避免 handler 中阻塞式 I/O 和 panic 泄漏
Go 的 HTTP server 每个请求跑在一个 goroutine 中，但若 handler 内部执行同步文件读写、未加超时的数据库查询、或调用未管控的 C 函数，会阻塞整个 P（GOMAXPROCS=1 时等于卡死全部请求）。
更隐蔽的问题是：panic 未被中间件 recover，会导致 goroutine 泄漏（Go 1.14+ 已改善，但仍可能积压）；或 log.Fatal 类调用直接终止进程。
- 所有外部调用（DB、Redis、HTTP client）必须设
context.WithTimeout，超时后主动 cancel - 禁止在 handler 中使用
time.Sleep模拟延迟 —— 改用select+time.After并检查 ctx.Done() - 用
defer func() { if r := recover(); r != nil { /* log & return 500 */ } }()包裹 handler 主逻辑，或统一用chi/middleware.Recoverer - 避免在 handler 中启动无监控的 goroutine（如
go sendEmail()）—— 必须带 cancelable context 并有错误反馈路径
实际压测中，把默认 mux 换成 chi、transport 连接池调优、handler 加上 context 超时，三者叠加常能将 p99 延迟降低 40% 以上。最容易被忽略的是 transport 的 MaxIdleConnsPerHost —— 很多人只改了全局 MaxIdleConns，却忘了 per-host 限制才是真实瓶颈。
