如何在Go微服务中通过自定义Middleware拦截器进行请求体大小限制

先说一个核心判断：在Go微服务里，别指望框架默认行为能帮你拦住大请求体。恶意客户端发一个500MB的POST请求，如果你的中间件链没有显式用http.MaxBytesReader包装r.Body，那结果就是OOM或者goroutine池被拖垮——就这么直接。

为什么标准中间件链里MaxBytesReader容易失效

这其实是个执行顺序的问题。中间件是按洋葱模型层层嵌套的，一旦某个上游中间件——比如JWT解析、日志记录——提前调用了r.ParseForm()或io.ReadAll(r.Body)，那么r.Body就会被消耗甚至关闭。等到你的限流中间件再登场时，包装的已经是一个空壳，毫无意义。

常见的误操作包括：自定义的auth中间件里顺手写了r.ParseForm()，然后才把请求交给业务handler，此时MaxBytesReader基本等于摆设。另一个坑是把http.MaxBytesHandler当成中间件塞进链里，但它包装的是整个http.Handler，不是单个请求流，和洋葱模型天生不兼容。框架层面，比如Gin的c.Request.Body是封装过的，但如果你在中间件里直接读它而没先包装，限流同样等于没设。

正确写法：中间件内尽早包装并只做一次

真正起作用的中间件，必须在ServeHTTP最开头就完成r.Body替换，并且确保下游所有handler都基于这个新Body读取。原理很简单，但实践中容易翻车的地方有两个：

• 包装逻辑必须放在next.ServeHTTP()调用之前，且只执行一次，不能重复包装
• 第一个参数传的是w（http.ResponseWriter），不是r；传错了直接panic
• 限制值建议按接口语义来设定，比如/login用2MB，/upload用50MB，避免一刀切

示例代码直接看这个：

func bodySizeLimitMiddleware(max int64) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            // ⚠️ 必须在任何读取前设置
            r.Body = http.MaxBytesReader(w, r.Body, max)
            next.ServeHTTP(w, r)
        })
    }
}

// 使用
r := mux.NewRouter()
r.Use(bodySizeLimitMiddleware(2 << 20)) // /login 等通用接口限 2MB
r.HandleFunc("/upload", uploadHandler).Methods("POST").Handler(
    bodySizeLimitMiddleware(50 << 20), // 单独为上传接口提上限
)

multipart场景下必须配合ParseMultipartForm参数

这里有个容易被忽略的细节：仅靠中间件里的MaxBytesReader，并不足以防住multipart攻击。攻击者可以发一个1KB的文本字段，再附上99MB的文件，总大小超限会被拦截——但如果你只设了100MB的总限，它就能轻松绕过。

正确的安全组合是：先用MaxBytesReader卡死总字节数（比如50MB），再调用r.ParseMultipartForm(8 << 20)把内存占用压到8MB以内。注意，ParseMultipartForm的maxMemory参数控制的是内存缓存阈值，超出部分会自动落盘，它本身不阻断上传。所以后续用r.FormFile()拿文件句柄，别用r.FormValue()依赖已解析的内存数据，否则可能触发二次读取，带来额外的风险。

错误处理必须显式检查http.ErrBodyTooLarge

这是一个最容易踩的坑。MaxBytesReader不会自动返回413状态码，它只是让后续的Read()调用返回http.ErrBodyTooLarge。你不检查这个错误，结果就是静默失败，或者诡异的io: read/write on closed pipe。

正确做法是在handler内部解码前加判断：if errors.Is(err, http.ErrBodyTooLarge)。不要指望中间件能统一捕获这个错误，因为标准http.Handler接口不暴露error返回值，中间件无法可靠拦截该错误类型。框架如Echo、Gin的binding方法（比如c.ShouldBindJSON()）内部已经处理了这个错误，但前提是你要确保它们读的是你包装过的c.Request.Body。

最后说一个容易被忽略的点：MaxBytesReader对slowloris类攻击无效。它只在读取时计数，连接仍然保持打开状态。所以完整的防护必须搭配http.Server.ReadTimeout和MaxHeaderBytes，缺一不可。