Go HTTP中间件需精简层级、合并语义紧密逻辑、提前失败、避免阻塞与分配、异步耗时操作、复用对象、扁平化链式调用、按需启用。
Go 的 HTTP 中间件本身轻量，但不当使用会累积明显开销——尤其在高并发、链路长（如认证→日志→限流→监控）的场景下。关键不在“去掉中间件”，而在让每层真正必要、执行高效、避免隐式成本。
减少中间件层级与提前终止
每多一层中间件，就多一次函数调用 + 一次 `http.Handler` 接口调度 + 可能的内存分配。实际中常见过度分层：比如把“检查用户是否登录”和“检查用户是否有某权限”拆成两个中间件，而它们本可合并为一次 DB/Cache 查询。
- 合并语义紧密的逻辑（如 auth + role check），避免重复解析 token 或查 session
- 在中间件入口快速失败：例如限流中间件在解析请求头后立刻判断是否拒绝，不继续调用 next
- 用布尔标记代替 panic 或 error 返回来跳过后续中间件（标准库不支持，但自定义链可实现 short-circuit）
避免中间件中的阻塞操作与内存分配
中间件里最常拖慢性能的是同步 I/O（如直接查 MySQL）、频繁字符串拼接、或无节制的 `log.Printf`。这些操作在请求路径上会放大延迟，且易成为 GC 压力源。
- 将耗时操作（如审计日志写入、指标上报）异步化：用 channel + worker goroutine 批量处理，中间件只发事件
- 复用对象：用 `sync.Pool` 缓存 `bytes.Buffer`、结构体实例；避免在中间件中反复 `make([]byte, ...)`
- 用 `strconv` 替代 `fmt.Sprintf` 做数字转字符串；用 `strings.Builder` 替代 `+` 拼接多个字符串
用函数式链替代嵌套 Handler 包装
标准 `func(http.Handler) http.Handler` 模式虽清晰，但每次包装都会新增一层闭包调用栈。当链长达 5–7 层时，函数调用开销可观。更高效的方式是构建扁平化的执行数组。
立即学习“go语言免费学习笔记（深入）”；
- 定义 `type Middleware func(http.ResponseWriter, *http.Request) bool`，返回 false 表示中断链
- 预编译中间件切片，在主 handler 中顺序执行，无嵌套闭包、无接口动态调度
- 示例：`for _, m := range middlewares { if !m(w, r) { return } }` —— 零额外分配，内联友好
按需启用中间件，而非全局注册
不是所有路由都需要全部中间件。给 `/healthz` 加 JWT 解析、给静态资源加 RBAC，纯属浪费 CPU 和上下文切换。
- 基于路由分组注册中间件（如 chi、gorilla/mux 的 `Group.Use()`），而非统一 wrap `http.DefaultServeMux`
- 对公开 API 路径（如 `/api/public/*`）跳过 auth 中间件；对上传接口单独禁用 request body 日志
- 用 `r.Context().Value()` 存标识位比每次都 `r.URL.Path` 匹配更快，但注意仅存轻量值（如 `int` 或 `uintptr`）
