HTTP中间件本质是http.Handler的嵌套包装，通过接收并返回实现ServeHTTP方法的处理器来链式组合逻辑，顺序决定执行时机，需注意闭包捕获、并发安全、请求体读取及路径匹配等陷阱。
HTTP中间件本质就是 http.Handler 的嵌套包装
Go 的 HTTP 中间件没有框架层抽象，它只是把一个 http.Handler 传给另一个函数，返回新的 http.Handler。核心就两行：next.ServeHTTP(w, r) 控制是否继续往后走，defer 或前置逻辑决定什么时候执行。
常见错误是写成闭包但忘了接收 http.Handler 参数，结果编译报错 cannot use func(http.ResponseWriter, *http.Request) as http.Handler —— 因为没实现 ServeHTTP 方法。
- 必须返回实现了
ServeHTTP方法的类型（通常是匿名函数或结构体） - 中间件函数本身不处理请求，只返回处理器；真正调用发生在路由注册时
- 顺序很重要：越靠前的中间件，越早拿到请求、越晚拿到响应
用函数型中间件最轻量，但要注意参数捕获陷阱
典型写法是定义一个接受 http.Handler 并返回 http.Handler 的函数，比如日志中间件：
func logging(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
log.Printf("→ %s %s", r.Method, r.URL.Path)
next.ServeHTTP(w, r)
log.Printf("← %s %s", r.Method, r.URL.Path)
})
}问题常出在闭包里误用循环变量：如果在 for 循环中批量注册中间件，又直接引用了循环变量 i 或 fn，所有中间件最终会共享最后一次迭代的值。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 解决方法：在循环内用局部变量显式拷贝，如
cur := fn; middleware = cur(...) - 不要在中间件内部修改
r.URL或r.Header后不 deep-copy 就传给下游——某些 Handler 会缓存原始字段 - 若需改写请求路径（如 prefix 剥离），推荐用
http.StripPrefix而非手动改r.URL.Path
带状态的中间件得用结构体，别滥用全局变量
需要配置参数（如超时时间、白名单 IP）或维护内部状态（如计数器、连接池）时，函数闭包容易失控。这时应该封装成结构体：
type rateLimiter struct {
limit int
bucket map[string]int
mu sync.RWMutex
}
<p>func (r <em>rateLimiter) ServeHTTP(w http.ResponseWriter, r </em>http.Request) {
// 实现限流逻辑
}很多人图省事把 bucket 放全局 map，结果并发写 panic 或数据错乱。Go 的 HTTP server 默认多 goroutine 并发处理请求，任何共享状态都必须加锁或用 sync.Map。
- 结构体字段如果是指针或 map/slice，初始化必须在构造函数里完成，不能依赖零值
- 不要在
ServeHTTP里启动 goroutine 处理耗时操作后直接返回——这会导致响应提前结束，客户端收不到数据 - 如果中间件要读取请求体（如鉴权校验 JSON），记得先
r.Body.Close()，否则下游 Handler 读不到内容
中间件链和 net/http.ServeMux 不兼容，得自己拼接
net/http.ServeMux 不支持中间件链式注册，你不能对某个 pattern 单独加中间件。想实现「/api/* 走鉴权，/static/* 不走」，必须手动组合：
http.Handle("/api/", logging(auth(apiHandler)))
http.Handle("/static/", staticHandler)
http.Handle("/", notFoundHandler)这时候容易踩的坑是路径匹配歧义：比如 /api/users 和 /api/ 都注册了 handler，ServeMux 会选最长前缀，但如果你中间件里又做了重写，就可能绕过预期逻辑。
- 避免混用
http.HandleFunc和http.Handle：前者自动转成http.HandlerFunc，后者要求显式实现接口，类型不一致容易漏掉中间件包装 - 调试时可在每个中间件开头加
log.Printf("[mid] %s → %s", r.Method, r.URL.Path)，快速定位哪一层断掉了 - 第三方路由库（如 chi、gorilla/mux）原生支持中间件链，但代价是引入额外抽象——纯
net/http场景下，老老实实手写组合最可控
中间件不是魔法，它只是函数组合的惯用写法。最难的从来不是怎么写，而是想清楚哪部分逻辑该放中间件、哪部分该进 Handler、哪部分其实该提成独立 service。尤其是涉及 context 传递、错误分类、超时控制时，边界一旦划错，后续 debug 成本翻倍。
