go中间件本质是包装http.handler的链式调用，需显式嵌套如authmiddleware(loggingmiddleware(handler))才能生效；不调用next.servehttp或提前写响应才会中断流程。
Go 语言中间件本身不“拦截”请求，而是通过包装 http.Handler 实现前置/后置逻辑插入；真正能中断流程的，只有你不调用 next.ServeHTTP(w, r) 或提前写响应并 return。
为什么 middleware 不是“注册即生效”的拦截器
Go 标准库没有全局中间件注册表或钩子机制。所谓“拦截”，本质是函数链式调用：你必须显式把 handler 包进 middleware 函数里，比如 authMiddleware(loggingMiddleware(myHandler))。如果漏掉某一层包装，那层逻辑就完全不会执行。
- 常见错误：在
http.HandleFunc("/", myHandler)后单独调用loggingMiddleware(...)却没赋值给任何变量——这行代码毫无效果 - 正确做法：要么用
http.Handle("/", middleware(handler))，要么用http.ListenAndServe(":8080", middleware(mux)) - 所有中间件都依赖闭包捕获
next，而 Go 的 goroutine 隔离保证了并发安全，无需额外加锁
如何在 middleware 中安全读取和修改 request.Body
request.Body 是 io.ReadCloser，只能读一次。你在中间件里调用 io.ReadAll(r.Body) 解析 JSON 或表单后，下游 handler 会读到空内容——这是最常导致 500 或静默失败的坑。
- 解决方法：用
r.Body = ioutil.NopCloser(bytes.NewReader(bodyBytes))（Go r.Body = io.NopCloser(bytes.NewReader(bodyBytes))（Go ≥ 1.16）重置 body - 更稳妥的做法：只在必要时读 body，并用
r = r.Clone(r.Context())创建新请求对象再修改，避免影响原始引用 - 若只是校验签名或提取 token，优先从
r.Header或r.URL.Query()获取，避开 body 操作
middleware 顺序错乱会导致什么问题
中间件执行是洋葱模型：外层 middleware 先进、后出。顺序不对，轻则逻辑失效，重则 panic 或 header 冲突。
- 鉴权必须在外层：如果
loggingMiddleware(authMiddleware(handler))，日志会在鉴权前打，且未授权请求也会被记录——应改为authMiddleware(loggingMiddleware(handler)) - 超时中间件要包住整个链：否则只对自身生效，无法终止下游阻塞操作
- 设置 CORS 或其他 response header 的中间件，必须在
next.ServeHTTP之后执行写 header 动作，否则可能被下游覆盖；但若提前写了，又会触发http: multiple response.WriteHeader calls错误
什么时候该用 http.RoundTripper 而不是 middleware
Middleware 只作用于服务端接收的请求；如果你要拦截**本机发出的 HTTP 请求**（比如调用第三方 API 前加 trace ID、过滤 GET 请求、mock 测试响应），就得换地方下手。
- 改
http.Client.Transport，实现自定义RoundTrip(*http.Request) (*http.Response, error) - 注意：
RoundTrip不处理重定向、cookie 等高层逻辑，那些由http.Client自己完成 - 不要在
RoundTrip里做耗时同步操作（如磁盘 I/O），它会阻塞整个 client 的请求队列
真正难的不是写一个中间件，而是判断哪段逻辑该放 middleware、哪段该放 handler 内部、哪段该下沉到 transport 层——边界模糊时，先问一句：这个操作影响的是“我收到的请求”，还是“我发出去的请求”，或是“我怎么解析它”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
