中间件函数签名必须是func(http.handler) http.handler，这是go net/http链式调用的唯一契约；接收http.handler、返回http.handler、显式调用next.servehttp(w, r)，缺一不可，否则中间件静默失效。
中间件函数签名必须是 func(http.Handler) http.Handler
这不是可选项，而是 Go 原生 net/http 中间件能被链式调用的唯一契约。写成 func(http.ResponseWriter, *http.Request) 或 func(http.HandlerFunc) 看似能编译，但传给 http.Handle() 时会被静默忽略——没有错误提示，请求直接绕过中间件，排查成本极高。
正确结构必须满足三点：
- 接收一个
http.Handler类型参数（即“下一个处理器”） - 返回一个新的
http.Handler - 在内部显式调用
next.ServeHTTP(w, r)，否则请求卡死
典型错误：把日志逻辑写成独立 handler 函数，再试图“塞进”路由；正确做法是包装它：loggingMiddleware(http.HandlerFunc(yourHandler))。
中间件顺序决定执行流和数据可见性
中间件是洋葱模型：最外层最先拿到请求、最后拿到响应。比如 logging(auth(handler))，执行顺序是 logging → auth → handler → auth → logging。这意味着：
- 鉴权中间件（如 JWT 解析）必须放在日志之前，否则日志里读不到
ctx.Value(userIDKey) - CORS 中间件得包在最外层，否则下游中间件提前
return，响应头就丢了 - 如果中间件 A 向 context 写值，中间件 B 读值，B 必须在 A 的下游（即包裹更内层），否则
ctx.Value()返回nil，类型断言 panic
常见翻车：循环注册中间件时用 for i := range ms { h = ms[i](h) }，导致所有中间件闭包捕获同一个 i，最终全指向最后一个中间件。
context 是跨中间件传数据的唯一安全方式
别用全局变量、包级变量或闭包捕获 request-scoped 数据（如用户 ID、请求 ID、DB transaction）。Go HTTP server 高并发，这些方式必然引发数据竞争或值污染。
正确姿势：
- 定义私有 key 类型：
type userIDKey struct{}，避免字符串 key 冲突 - 写入：
ctx := r.Context().WithValue(userIDKey{}, userID) - 更新请求：
r = r.WithContext(ctx)，再传给next.ServeHTTP(w, r) - 读取：
if uid, ok := r.Context().Value(userIDKey{}).(string); ok { ... }，务必判空和类型断言
注意：context.Background() 和 context.TODO() 没有 cancel 和 timeout，不能替代 r.Context()。
必须手动处理 OPTIONS 预检和 panic 恢复
浏览器发 CORS 请求前必先发 OPTIONS 预检，net/http 默认不响应，直接 404，后续所有 header 设置都无效。
手写中间件时，必须显式处理：
-
if r.Method == "OPTIONS" { w.WriteHeader(204); return }—— 不能只设 header，必须写状态码 - panic 不会自动 recover，整个请求直接 500。recover 要放在最外层中间件（如 logging），否则内层 panic 逃逸出去
- 外部服务调用（Redis/gRPC）必须带
ctx.WithTimeout()，标准http.ServeMux不提供超时控制
真正容易被忽略的点：中间件里多次读 r.Body 会失败（body 是 io.ReadCloser，读完即空），需要提前 io.ReadAll() 并用 http.Request.Clone() 重建请求体，否则下游 handler 拿不到原始数据。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
