Go HTTP中间件本质是func(http.Handler) http.Handler的链式调用，通过包装Handler实现前置/后置逻辑，需正确调用next.ServeHTTP(w,r)，并用自定义ResponseWriterWrapper拦截响应状态与数据。
Go HTTP 中间件的本质是函数链式调用
Go 标准库的 http.Handler 接口只定义了一个 ServeHTTP 方法，中间件不是语言内置概念，而是通过高阶函数包装 http.Handler 实现的。核心思路是：每个中间件接收一个 http.Handler，返回一个新的 http.Handler，并在其 ServeHTTP 中完成前置/后置逻辑。
常见错误是试图在中间件里直接 return 响应而不调用下一个 handler，导致请求链中断。正确做法是显式调用 next.ServeHTTP(w, r)。
- 中间件函数签名必须是
func(http.Handler) http.Handler - 不能用闭包捕获
http.ResponseWriter后再修改 —— 它是一次性写入的，写完即发送 - 若需修改响应体（如压缩、加 header），应包装
http.ResponseWriter实现自定义类型
如何包装 ResponseWriter 实现响应拦截
标准 http.ResponseWriter 不暴露状态，无法判断是否已写入。要实现日志记录状态码、响应体大小或 gzip 压缩，必须用结构体嵌入原接口并重写方法。
典型场景：记录实际返回的状态码（而非默认 200）、统计响应时长、添加 X-Response-Time header。
立即学习“go语言免费学习笔记（深入）”；
type responseWriterWrapper struct {
http.ResponseWriter
statusCode int
written bool
}
func (w *responseWriterWrapper) WriteHeader(code int) {
w.statusCode = code
w.written = true
w.ResponseWriter.WriteHeader(code)
}
func (w *responseWriterWrapper) Write(b []byte) (int, error) {
if !w.written {
w.WriteHeader(http.StatusOK)
}
return w.ResponseWriter.Write(b)
}
-
WriteHeader必须只调用一次，所以用written标记避免重复调用 - 不要在
Write里调用WriteHeader两次，否则 panic - 若需读取/修改响应体（如模板渲染后注入脚本），得用
bytes.Buffer缓存，但要注意内存占用
gorilla/mux 或 chi 路由器的中间件注册差异
标准库 http.ServeMux 不支持中间件注册，必须手动链式调用；而 gorilla/mux 和 chi 提供了 Use 或 With 方法，但底层仍是函数链，只是语法更简洁。
关键区别在于作用域：全局中间件（对所有路由生效） vs 路由组中间件（仅匹配某路径前缀）。
-
gorilla/mux的router.Use(middleware1, middleware2)是全局的；子路由用subRouter := router.PathPrefix("/api").Subrouter()再Use可限定范围 -
chi的r.With(authMiddleware).Get("/user", handler)更灵活，支持 per-route 中间件组合 - 混用不同中间件风格（比如在 chi 中套一层标准库中间件链）容易导致
ResponseWriter包装丢失，状态码记录失效
中间件顺序错误会导致逻辑失效
中间件执行顺序严格依赖包装顺序：最外层中间件最先执行，也最后结束；内层中间件在中间执行。顺序错乱会引发严重问题。
典型反例：把日志中间件放在 gzip 中间件外层，但日志依赖响应体长度 —— 此时读到的是压缩后字节数，而非原始长度。
- 鉴权中间件必须在业务 handler 前，否则未授权请求仍会执行业务逻辑
- 恢复 panic 的
recover中间件必须是最外层，否则 panic 会穿透出去 - gzip 压缩应在日志、指标中间件之后（因为它们需要原始响应数据），但在写入
ResponseWriter之前 - 所有中间件共用同一个请求上下文（
context.Context），但修改r = r.WithContext(...)不会影响外层中间件已持有的旧r
真正难调试的，往往是中间件之间对 ResponseWriter 的多次包装与解包不一致，或者 context key 冲突 —— 这些不会报错，只会让日志、超时、追踪信息错位。
