go中间件必须返回http.handler而非直接调用next.servehttp()，因其本质是包装器，需被路由链式挂载；直接调用会跳过后续中间件且无法控制请求生命周期。
Go HTTP 中间件为什么必须返回 http.Handler 而不是直接调用 next.ServeHTTP()
因为中间件本质是“包装”而非“执行”，返回新 http.Handler 才能被标准路由（如 http.ServeMux 或 chi.router）链式挂载。直接调用 next.ServeHTTP() 会跳过后续中间件，且无法参与请求生命周期控制。
- 常见错误：在中间件函数里写
next.ServeHTTP(w, r)后就 return，没用闭包封装成新 Handler —— 这会导致中间件只生效一次，无法复用 - 正确姿势是用闭包捕获
next，返回一个匿名http.Handler函数：func Logging(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { log.Println(r.Method, r.URL.Path) next.ServeHTTP(w, r) }) } - 不返回
http.Handler的写法无法和chi.Use()、gorilla/mux.Router.Use()等主流路由器兼容
如何让中间件支持配置参数（比如日志级别、超时时间）
Go 没有装饰器语法，所谓“带参中间件”其实是高阶函数：外层接收配置，内层返回中间件函数。参数应在中间件初始化时传入，而非每次请求都解析。
- 错误示范：
func auth(role String) http.Handler—— 这样每个角色都要新建一个中间件实例，冗余且难管理 - 推荐模式：配置结构体 + 选项函数（functional options），例如
type AuthConfig struct { AllowAdmin bool TokenKey string } func WithAdminAccess() Option { return func(c *AuthConfig) { c.AllowAdmin = true } } func Auth(opts ...Option) func(http.Handler) http.Handler { ... } - 注意：配置值不能是全局变量或闭包外可变状态，否则并发请求会互相污染
为什么 http.HandlerFunc 要显式转换，而不能直接返回普通函数
因为 http.Handler 是接口，定义了 ServeHTTP(http.ResponseWriter, *http.Request) 方法；普通函数只是值，没有实现该接口。显式转换是 Go 类型系统强制的安全检查。
- 编译错误典型提示：
cannot use func literal (type func(http.ResponseWriter, *http.Request)) as type http.Handler in return argument -
http.HandlerFunc是类型别名，它的底层方法实现了http.Handler接口，所以http.HandlerFunc(f)是合法转换 - 漏掉转换会导致中间件“静默失效”——编译不过，或者误传为
nil导致 panic
多个中间件嵌套时，panic 恢复中间件为什么必须放在最外层
中间件执行顺序是“先进后出”（类似栈），recover() 只能捕获当前 goroutine 中、且尚未被上层处理的 panic。如果恢复中间件在内层，外层中间件抛出的 panic 它根本看不到。
立即学习“go语言免费学习笔记（深入）”；
- 错误顺序：
logging → auth → recover → serve—— 此时recover在第三层，前面两层的 panic 已经穿透出去了 - 正确顺序：
recover → logging → auth → serve—— 所有下层 panic 都会被第一层捕获 - 实战建议：用
defer+recover包裹整个ServeHTTP流程，并手动设置 status code 和响应体，避免裸奔返回 500
中间件链的执行流和错误传播方向容易反直觉，尤其是 recover 和 defer 的作用域边界。写的时候多打几行 log，用 runtime.Caller 看调用栈，比猜快得多。