HTTP中间件是通过包装原始handler实现前置处理的函数，不能直接修改http.HandleFunc因ServeMux无拦截能力；必须返回新Handler，按洋葱模型嵌套，常用闭包或结构体封装。
什么是 HTTP 中间件，为什么不能直接改 http.HandleFunc
Go 的 http.ServeMux 本身不提供「拦截」能力，http.HandleFunc 注册的是终态处理器（http.HandlerFunc），一旦匹配就直接执行，没有钩子可插。所谓「前置处理」，本质是把原始 handler 包一层新函数，在调用原 handler 前做检查、日志、鉴权等操作——这就是中间件的实现原理。
常见错误是试图在 http.HandleFunc 内部做逻辑判断后跳过后续处理，结果发现无法控制流程（比如想拒绝请求却仍继续执行），根本原因是没理解 Go HTTP 处理链是单向的，必须靠「包装」而非「修改」。
- 中间件必须返回一个新的
http.Handler或http.HandlerFunc - 原始 handler 必须作为参数传入中间件，不能硬编码或全局引用
- 多个中间件要按顺序嵌套，外层先执行，内层最后执行（洋葱模型）
用闭包实现简单鉴权中间件
最轻量的写法是闭包：一个接受 http.Handler 并返回新 http.Handler 的函数。它能捕获外部变量（如密钥、白名单），适合配置固定的前置逻辑。
func AuthMiddleware(secret string) func(http.Handler) http.Handler {
return func(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
token := r.Header.Get("X-API-Key")
if token != secret {
http.Error(w, "Forbidden", http.StatusForbidden)
return
}
next.ServeHTTP(w, r) // 放行给下一层
})
}
}
使用时注意顺序和嵌套方式：
立即学习“go语言免费学习笔记（深入）”；
-
AuthMiddleware("abc123")(loggingMiddleware(http.HandlerFunc(myHandler)))—— 先鉴权，再打日志，最后进业务 - 如果漏掉
next.ServeHTTP(w, r)，请求会卡住，无响应也无错误 - 闭包捕获的
secret是值拷贝，线程安全；但若传指针或 map，需自行同步
用结构体封装可配置中间件（如日志 + 超时）
当需要复用、组合或动态配置（比如开关日志、设置超时秒数），结构体比闭包更清晰。关键点在于：结构体字段存配置，Wrap 方法返回包装函数，ServeHTTP 实现实际逻辑。
type LoggingMiddleware struct {
Enabled bool
}
func (l LoggingMiddleware) Wrap(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if l.Enabled {
log.Printf("START %s %s", r.Method, r.URL.Path)
defer log.Printf("END %s %s", r.Method, r.URL.Path)
}
next.ServeHTTP(w, r)
})
}
type TimeoutMiddleware struct {
Seconds int
}
func (t TimeoutMiddleware) Wrap(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
ctx, cancel := context.WithTimeout(r.Context(), time.Duration(t.Seconds)*time.Second)
defer cancel()
r = r.WithContext(ctx)
done := make(chan struct{})
go func() {
next.ServeHTTP(w, r)
close(done)
}()
select {
case <-done:
case <-ctx.Done():
http.Error(w, "Request timeout", http.StatusGatewayTimeout)
}
})
}
这种写法的优势：
- 配置项显式暴露为字段，IDE 可提示，测试易 mock
-
Wrap方法统一接口，方便链式调用：timeout.Wrap(logging.Wrap(handler)) - 超时中间件中必须用
r.WithContext()替换原请求，否则下游 handler 拿不到新 context
为什么 http.StripPrefix 不算真正中间件
http.StripPrefix 看似是前置处理，但它只修改 r.URL.Path，不干预执行流程，也不支持条件跳过或注入逻辑。它属于路由预处理，不是中间件。真正的中间件必须满足两个条件：能读写 request/response、能决定是否调用 next。
容易混淆的点：
-
http.StripPrefix("/api", h)本质是新建一个http.ServeMux子路由，不是包装 handler - 它无法获取 header、body，也不能记录耗时或做鉴权——这些必须靠自定义 handler 包装
- 若混用
StripPrefix和中间件，注意路径已被截断，中间件里看到的r.URL.Path是去前缀后的
复杂中间件往往要同时处理 context 传递、panic 恢复、body 重放（如鉴权需读 body）、response writer 包装（用于统计状态码）——这些都不是开箱即用的，得一层层自己补全。
