go http中间件本质是装饰器函数，签名固定为func(http.handler) http.handler，需显式转换http.handlerfunc，错误遗漏return会导致重复执行；工厂函数支持初始化，顺序、responsewriter包装和context传递是关键边界点。
Go HTTP中间件本质就是装饰器函数
Go 没有语言级装饰器语法，但 http.Handler 和 http.HandlerFunc 的签名天然支持链式包装——中间件就是接收 http.Handler、返回新 http.Handler 的函数。这不是模拟，是直接基于类型系统实现的装饰器模式。
常见错误是把中间件写成“处理逻辑后直接调用 next.ServeHTTP()”却忘了加 return，导致后续中间件或主 handler 重复执行；或者误以为必须用闭包捕获参数，其实多数场景传参更清晰可靠。
- 中间件函数签名固定为：
func(http.Handler) http.Handler - 要兼容
http.HandlerFunc，需用http.Handler(next)显式转换（尤其在嵌套多层时） - 若中间件需初始化（如带日志前缀、配置超时），必须用工厂函数：
func(string) func(http.Handler) http.Handler
为什么 next.ServeHTTP(w, r) 前不加 return 会出问题
典型现象：日志打两遍、响应体被写入两次、http: multiple response.WriteHeader calls 错误。根本原因是 Go 中函数不会自动终止执行流，ServeHTTP 调用只是普通函数调用，不是控制转移。
使用场景：所有需要“前置逻辑 + 转发 + 后置逻辑”的中间件，比如鉴权后记录耗时、panic 恢复后统一返回错误页。
立即学习“go语言免费学习笔记（深入）”；
- 前置逻辑后必须判断是否应中断流程（如未登录），此时要
return -
next.ServeHTTP(w, r)后若还有清理或统计代码，无需return；但若已写响应（如重定向、401），必须return阻止继续执行 - 别依赖 defer 做“后置逻辑”，因为
defer在函数返回时才执行，而ServeHTTP可能已写出响应头
http.HandlerFunc 和 http.Handler 混用时的类型陷阱
错误信息常为：cannot use myHandler (type func(http.ResponseWriter, *http.Request)) as type http.Handler 或相反。根本在于：Go 接口是隐式实现，但类型系统严格区分具名类型和函数字面量。
性能影响几乎为零，但兼容性差会导致编译失败或意外 panic（尤其在反射或泛型约束中）。
-
http.HandlerFunc是类型别名，实现了http.Handler接口的ServeHTTP方法 - 中间件工厂返回值应统一用
func(http.Handler) http.Handler，内部用http.Handler(fn)转换 handler 函数 - 不要对
http.HandlerFunc做类型断言，比如h.(http.HandlerFunc)—— 它可能是一个自定义 struct 实现的http.Handler
真实项目里容易被忽略的边界点
不是语法问题，而是运行时行为：中间件顺序不可逆、ResponseWriter 包装不足、context 传递断裂。这些在本地测试时很难暴露，上线后才出现超时、日志丢失、trace ID 断链。
- 中间件顺序决定执行顺序，
logging → auth → metrics和auth → logging → metrics的日志内容和耗时统计完全不同 - 若需修改响应（如压缩、加 header），必须包装
http.ResponseWriter，直接写w.Header().Set()在next.ServeHTTP()后无效 - 所有中间件都该用
r = r.WithContext(...)更新context，否则下游 handler 拿不到 trace ID 或超时控制
装饰器的价值不在“看起来像 Python 的 @decorator”，而在每一层只专注一件事，并且能精确控制调用时机和数据流向。写错一层，整条链就偏了。
