中间件必须实现http.Handler接口（如匿名结构体或闭包），签名应为func(http.Handler) http.Handler，通过嵌套调用（如auth(mw2(mw1(handler)))）构建链；需用r.Clone()安全修改请求，避免body重复读取或并发竞争，且所有网络操作须基于r.Context()派生子ctx以配合http.Server生命周期管理。

中间件怎么套进 http.ServeMux 才不丢请求上下文

标准库的 http.ServeMux 不支持中间件链，直接用 HandleFunc 会绕过你写的包装逻辑。必须把中间件转成符合 http.Handler 接口的类型，否则 next.ServeHTTP 一调就 panic：「nil pointer dereference」或者请求根本没进你的日志/鉴权逻辑。

• 别写 func(http.ResponseWriter, *http.Request) 然后塞给 HandleFunc —— 这只是 handler 函数，不是可嵌套的 http.Handler
• 中间件函数签名得是 func(http.Handler) http.Handler，返回一个新 http.Handler 实例
• 最简封装就是用匿名结构体或闭包实现 ServerHTTP 方法，比如：

  type loggingHandler struct {
      next http.Handler
  }
  func (h loggingHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
      log.Printf("req: %s %s", r.Method, r.URL.Path)
      h.next.ServeHTTP(w, r)
  }

• 如果用闭包，注意捕获的 next 必须是非 nil；常见错误是传了 nil http.Handler 给中间件，运行时报 panic: runtime error: invalid memory address

为什么 http.HandlerFunc 转 http.Handler 后还能链式调用

http.HandlerFunc 是函数类型，但它实现了 http.Handler 接口（有 ServeHTTP 方法），所以能被中间件接收和返回。关键在「转换时机」：中间件不关心里面是 struct 还是函数，只认接口。

• 中间件输入是 http.Handler，输出也必须是 http.Handler；http.HandlerFunc(f) 就是把普通函数 f 变成满足接口的实例
• 链式调用本质是嵌套： auth(mw2(mw1(handler)))，最里层 handler 是最终业务逻辑，外层每次 wrap 都新增一层逻辑
• 性能上无额外开销——接口调用是静态绑定，Go 编译器能内联简单中间件；但别在中间件里做同步阻塞操作（如未设 timeout 的 HTTP 调用），会卡住整个链
• 兼容性没问题：所有 Go 版本都支持，http.Handler 接口自 1.0 未变

net/http 中间件里怎么安全读取和修改 *http.Request

不能直接改 r.URL.Path 或 r.Header 后就 return，下游 handler 可能依赖原始值。要改就得用 r.Clone()，否则并发下会出数据竞争或脏写。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 读取 body 前必须先 r.Body = ioutil.NopCloser(bytes.NewBuffer(buf))，否则后续 handler 再读就是空 —— 因为 Body 是单次读取流
• 修改 path、query 或 header 应该新建 request：

  newReq := r.Clone(r.Context())
  newReq.URL.Path = "/api/v2" + r.URL.Path
  newReq.Header.Set("X-Processed", "true")

• 不要在中间件里调 r.ParseForm() 或 r.ParseMultipartForm()，除非你确定下游不需要原始 raw body；否则会提前消费 body，导致 json.Decode 失败
• 常见错误现象：http: panic serving [::1]:54321: invalid memory address or nil pointer dereference，往往是因为中间件里用了已关闭的 r.Body

标准库中间件链如何跟 http.Server 生命周期对齐

中间件本身没生命周期管理，但它的行为受 http.Server 的 ReadTimeout、IdleTimeout 和 Handler 字段影响。如果中间件里做了耗时操作（比如 DB 查询、远程调用），没主动控制超时，就会拖垮整个 server。

立即学习“go语言免费学习笔记（深入）”；

• http.Server 的 Handler 字段填的是最外层中间件返回的 http.Handler，它决定了所有请求入口；别漏掉这一步，否则启动后全是 404
• 中间件里的网络调用必须带 context：用 r.Context() 派生子 ctx，并传给下游 client；否则 Server.Shutdown() 时请求不会中断，变成 goroutine 泄漏
• 不要在中间件里启动 goroutine 处理请求（如 go handleAsync(r)），除非你手动管理其生命周期；标准库的 handler 要求同步完成 ServeHTTP
• 容易被忽略的一点：中间件顺序决定执行顺序，比如 recovery 必须包在最外层，否则 panic 会直接透出，而 logging 放最里层就看不到其他中间件是否执行成功

事情说清了就结束