必须显式使用http.maxbytesreader或http.maxbyteshandler，因go框架默认不限制请求体大小，否则恶意大请求会引发oom或拖垮连接池；gin/echo的bodysizelimit配置仅在r.body被读取前完成包装才生效，若中间件提前解析或handler绕过绑定直接解码，则限流失效；multipart场景需组合使用http.maxbytesreader限制总大小与parsemultipartform控制内存缓存，避免文件+表单字段绕过限制。
必须显式使用 http.MaxBytesReader 或 http.MaxBytesHandler，框架默认不限制请求体大小，不加这层限制，恶意 2GB POST 请求会直接触发 OOM 或拖垮连接池。
为什么 Gin/Echo 的 BodySizeLimit 配置有时完全失效
框架配置（如 e.MaxRequestBodySize 或 gin.DefaultWriter）底层确实是调用 http.MaxBytesReader，但它的生效前提是：包装操作必须发生在任何 r.Body 读取之前。一旦被提前消费，限流就形同虚设。
- 自定义 JWT 中间件里调了
r.ParseForm()或io.ReadAll(r.Body)→ 原始r.Body已空，后续框架包装无效 - handler 中绕过
c.ShouldBindJSON()，直接用json.NewDecoder(c.Request.Body).Decode()→ 没手动套http.MaxBytesReader，等于裸奔 - 用了自定义
gin.Engine实例但没确认gin.DefaultWriter是否启用限流（v1.9+ 默认开，但自定义时可能被覆盖）
multipart/form-data 场景下只限总大小远远不够
http.MaxBytesReader 对整个请求体计数，但 multipart 请求里表单字段和文件混在一起。攻击者可发一个 1KB 文本字段 + 99MB 文件，轻松绕过“总大小 10MB”的限制——因为 r.ParseMultipartForm(maxMemory) 的 maxMemory 参数只控制内存缓存部分，超出自动落盘，不拦总上传量。
- 真正有效的组合是：
r.Body = http.MaxBytesReader(w, r.Body, 50（先卡死总上传量，比如 50MB） - 再调
r.ParseMultipartForm(8 （设较小的 <code>maxMemory，比如 8MB，让小文件走内存、大文件落盘） - 最后用
r.FormFile("file")获取磁盘句柄，而非r.FormValue()（后者只读文本字段，且依赖已解析的内存数据）
全局统一限流用 MaxBytesHandler，差异化限流用 MaxBytesReader
http.MaxBytesHandler 包裹整个 http.Handler，在路由匹配前就拦截超限请求，返回 413 并关闭 TCP 连接，最安全、不易遗漏；但它无法区分接口语义——/login 和 /upload 被迫共用同一上限。
- 所有接口统一宽松上限（如 10MB）→ 直接用
http.MaxBytesHandler(r, 10 - 需要差异化（如
/login限 2MB，/upload限 100MB）→ 用http.MaxBytesReader，并在中间件中按路由路径动态赋值r.Body - 无论哪种，都必须配合
http.Server.ReadTimeout和http.Server.MaxHeaderBytes，否则头部膨胀或慢速读取攻击仍可绕过 Body 限制
最容易被忽略的是顺序问题：限流必须在任何 r.Body.Read()、r.ParseForm()、io.ReadAll() 之前完成，且赋值回 r.Body；其次是 multipart 场景下误以为 ParseMultipartForm 的 maxMemory 能控总大小——它不能。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
