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 包装（用于统计状态码）——这些都不是开箱即用的，得一层层自己补全。