http.MaxBytesReader 必须在读取 Body 前生效：Gin 不自动限流，该函数仅在 r.Body 首次读取前包装才有效；若中间件提前调用 ParseForm 或 ReadAll，则原始 Body 已被消费，后续包装无效。
http.MaxBytesReader 必须在读 Body 前生效
Gin 框架本身不自动限制请求体大小，http.MaxBytesReader 是底层唯一可靠的限流手段。它只在 r.Body 被首次读取前包装才有效——一旦中间件（比如 JWT 验证）调用了 r.ParseForm() 或 io.ReadAll(r.Body)，原始 Body 就已被消费，后续再包也无效。
- 必须把
r.Body = http.MaxBytesReader(w, r.Body, 50 放在 handler 开头，且早于任何 <code>c.ShouldBindJSON()、c.PostForm()、c.FormFile() - 传参顺序不能错：
http.MaxBytesReader(w, r.Body, limit)，第二个参数是r.Body，第三个是字节数；传错成r会 panic - 错误类型是
http.ErrContentLength，不是http.ErrBodyTooLarge（后者是ParseForm等内部方法用的）
Gin 的 MaxMultipartMemory 不是总大小限制
r.ParseMultipartForm(32 中的 <code>32（默认 32MB）只控制「非文件字段」的内存缓冲上限，文件内容仍会流式写入临时磁盘。攻击者可发一个 1KB 表单 + 99MB 文件，只要总请求体没超 <code>MaxBytesReader 限制，这个 32 完全拦不住。
-
gin.Engine.MaxMultipartMemory影响的是c.PostForm()是否能读到文本字段——它依赖formCache，而 cache 只在ParseMultipartForm成功后填充 - 若只处理纯文本字段，
c.ShouldBind(&struct{})更可靠，它会主动触发完整解析 - 若需细粒度控制（如上传接口 50MB、普通 API 2MB），必须 per-handler 手动调
http.MaxBytesReader，不能只靠全局配置
multipart 场景下必须组合使用两个限制
单靠 http.MaxBytesReader 或单靠 ParseMultipartForm 都不安全。前者防不住小表单+大文件绕过，后者不限制总上传体积。真正有效的组合是：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先用
r.Body = http.MaxBytesReader(w, r.Body, 50 卡死总请求体（如 50MB） - 再调
r.ParseMultipartForm(8，设较小的 <code>maxMemory（如 8MB），让小字段走内存、大文件落磁盘，但总大小已被前置卡死 - 最后用
r.FormFile("file")获取句柄，而不是r.FormValue()（后者只读缓存里的文本字段）
框架配置项容易被误认为“已生效”
Gin v1.9+ 的 e.MaxRequestBodySize = 10 * 1024 * 1024 确实安全，因为它在 http.ServeHTTP 入口就完成了包装。但如果你：自定义了 gin.Engine 实例、替换了 gin.DefaultWriter、或在中间件里提前读了 Body，这个配置就可能失效。
立即学习“go语言免费学习笔记（深入）”；
- 别假设“开了配置就万事大吉”——用 curl 发个 101MB 文件测试，看是否真返回 413
-
gin.SetMode(gin.ReleaseMode)和gin.DebugMode都不影响大小限制，但调试日志可能掩盖真实错误（比如把ErrContentLength吞掉） - 如果用了自定义中间件（如权限校验），务必检查它是否调了
r.ParseForm()或io.ReadAll(r.Body)
最常被忽略的一点：multipart 场景下，http.MaxBytesReader 限制的是整个 HTTP 请求体（包括 boundary、字段、文件），而 ParseMultipartForm 的 maxMemory 只管表单字段内存占用。这两个值语义完全不同，必须同时设、且数值要匹配业务预期。
