gin框架本身不设默认请求体大小限制，必须显式使用http.maxbytesreader在handler第一行包装r.body，否则中间件提前读取或绕过绑定会导致限流失效。
Gin 框架本身不设默认请求体大小限制，不显式控制就会被大 Body 拖垮内存或触发 OOM —— 这不是配置漏了，而是根本没闸门。
为什么 Gin 的 MaxRequestBodySize 有时完全失效
它本质是调用 http.MaxBytesReader，但只在 r.Body 第一次被读取前生效。一旦中间件或业务逻辑提前消费了 Body，框架的限流就形同虚设。
- JWT 中间件里写了
r.ParseForm()或io.ReadAll(r.Body)→ Body 已空，后续限流无效 - handler 里绕过
c.ShouldBindJSON()，直接用json.NewDecoder(c.Request.Body).Decode()→ 框架限流没覆盖到这段逻辑 - Gin v1.9+ 默认启用限流，但如果你用
gin.New()创建 engine 并替换gin.DefaultWriter，可能意外关闭底层包装
http.MaxBytesReader 必须写在 handler 第一行
这不是“建议”，是强制顺序：必须在任何读取操作之前赋值给 r.Body，否则计数器根本没启动。
- 正确姿势：
c.Request.Body = http.MaxBytesReader(c.Writer, c.Request.Body, 2（2MB） - 错误写法：
http.MaxBytesReader(...)但没赋值给c.Request.Body→ 白写 - 别在 defer 前漏掉这行，否则
c.Request.Body.Close()可能 panic - 如果用了
c.MultipartReader()或c.FormFile()，也得在这之前完成包装
multipart 场景下，ParseMultipartForm 的 maxMemory 不是总大小限制
r.ParseMultipartForm(8 只控制最多多少字节留在内存里，超出部分自动落盘 —— 攻击者发一个 1KB 表单 + 99MB 文件，照样通过。
- 真正有效的组合：
r.Body = http.MaxBytesReader(..., 50（先卡死总上传量） - 再调
r.ParseMultipartForm(8 （小字段走内存，大文件落盘） - 用
r.FormFile("file")拿磁盘句柄，别用r.FormValue()读大字段 router.MaxMultipartMemory = 8 是 Gin 对 <code>ParseMultipartForm的封装，不能替代总限流
全局限流用 http.MaxBytesHandler，差异化限流才用 MaxBytesReader
MaxBytesHandler 包裹整个 http.Handler，在路由匹配前就拦截超限请求，返回 413 并断连，最稳；但它无法按接口语义区分上限。
- 所有接口统一宽松上限（如 10MB）→ 直接套
http.MaxBytesHandler(mux, 10 - 需要登录接口限 2MB、上传接口限 100MB → 用
MaxBytesReader，并在中间件里根据c.FullPath()动态赋值 - 别忘了配
http.Server.ReadTimeout，防止慢速大 Body 持续占用连接 -
http.Server.MaxHeaderBytes要单独设（如 8KB），它和 Body 限流互不覆盖
最容易被忽略的是：你写的每一行读 Body 的代码，都必须确认前面有没有 r.Body = http.MaxBytesReader(...) —— 尤其是中间件、自定义解析、gRPC over HTTP/2 场景，漏一处就等于整条链路失防。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
