go http中间件是接收并返回http.handler的函数，需调用next.servehttp(w, r)传递请求；前置/后置操作分别实现钩子逻辑；recover中间件须防重复写响应；gin等框架中间件因接口不兼容不可直用于net/http；中间件顺序遵循洋葱模型，影响执行逻辑与上下文数据。
什么是 Go HTTP 中间件，它到底长什么样
Go 里没有“中间件”这个内置概念，它只是开发者对 http.Handler 链式封装的约定俗成叫法。本质就是一个接受 http.Handler 并返回新 http.Handler 的函数，比如：func(loggingMiddleware(http.Handler)) http.Handler。
关键点在于：它必须调用 next.ServeHTTP(w, r) 才能让请求继续向下传递——漏掉这句，后续 handler 就永远不会执行。
- 不调用
next.ServeHTTP→ 请求在此中断（可用于鉴权拦截） - 在
next.ServeHTTP前操作 → 类似“前置钩子”（记录开始时间、修改 header） - 在
next.ServeHTTP后操作 → 类似“后置钩子”（记录耗时、重写响应体）
如何手写一个带错误恢复的中间件
生产环境最常踩的坑是 panic 导致整个服务挂掉。标准 http.ServeHTTP 不捕获 panic，必须自己包一层。
典型实现要兼顾两点：恢复 panic + 防止重复写 response（因为 http.ResponseWriter 写完再写会 panic）。
立即学习“go语言免费学习笔记（深入）”；
- 用
http.NewResponseWriter包装原始http.ResponseWriter，监听是否已写入 - 用
defer+recover()捕获 panic - 恢复后统一返回
500 internal Server Error，并记录堆栈（别直接暴露给前端）
示例核心逻辑：
func recoverMiddleware(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { defer func() { if err := recover(); err != nil { http.Error(w, "Internal Server Error", http.StatusInternalServerError) log.Printf("panic: %vn%v", err, debug.Stack()) } }() next.ServeHTTP(w, r) }) }为什么 Gin/echo 的中间件不能直接用在 net/http 上
因为接口不兼容：gin.HandlerFunc 是 func(*gin.Context)，而标准库是 func(http.ResponseWriter, *http.Request)。强行混用会导致编译失败或运行时 panic。
- Gin 的
*gin.Context是封装体，包含 request/response/params/error 等字段，还自带Next()控制流程 - net/http 的中间件只能操作原始
http.ResponseWriter和*http.Request，没法访问 Gin 特有的上下文数据 - 如果项目用了 Gin，就别试图把 net/http 中间件塞进
router.Use()—— 类型根本对不上
多个中间件的顺序为什么不能随便调换
中间件是洋葱模型：外层先执行前半段，到最内层 handler 后，再从内往外执行后半段。顺序错，逻辑就崩。
- 日志中间件放在最外层 → 能统计所有请求（包括被鉴权拒绝的）
- JWT 验证中间件必须在业务 handler 前 → 否则业务代码拿到未验证的用户 ID
- 跨域中间件（CORS）通常放最外层 → 确保预检请求（OPTIONS）也能被正确响应
- 如果把限流中间件放在 recover 之后，panic 会导致限流计数器没更新，可能引发误放行
真正容易被忽略的是：中间件内部的副作用（比如修改 r.Context()）依赖顺序。一旦改了顺序，ctx.Value() 取不到值，业务 handler 就会 panic。