router.MaxMultipartMemory不能真正限制上传文件大小，因为它仅控制内存缓冲区上限，超限后自动落盘而非拦截请求；真正有效的防护是必须在handler开头用http.MaxBytesReader包装r.Body，在首次Read前硬性截断总请求体。
为什么 router.MaxMultipartMemory 不能真正限制上传文件大小
router.MaxMultipartMemory 只控制 multipart 解析时内存缓冲区上限（默认 32MB），超限后自动落盘到临时文件——它不阻止客户端继续发送数据。哪怕你设成 1（即 8MiB），攻击者仍可发 500MB 的 multipart/form-data 请求，服务端照单全收，只是把超出内存的部分写进磁盘，照样耗尽 I/O 和磁盘空间。
更危险的是：header.Size 是从 multipart boundary 中解析出的字段，完全可被伪造；r.ParseMultipartForm() 或 c.FormFile() 调用时，请求体早已开始读取，防护窗口已关闭。
- 它只影响“内存缓存策略”，不是流量闸门
- 对
Transfer-Encoding: chunked请求完全无效（此时r.ContentLength == -1） - 前端校验、JS 拦截、表单
maxFileSize属性统统可绕过
必须在 handler 开头用 http.MaxBytesReader 硬拦截
唯一能“拦在最前面”的方式，是用 http.MaxBytesReader 包装 r.Body，在每次 Read() 时实时计数，超限立即返回 io.EOF 或 http.ErrBodyReadAfterClose，强制断连。
正确顺序只有一条：必须在任何触发 body 读取的操作之前执行，包括 c.FormFile()、c.MultipartForm()、c.Request.ParseMultipartForm()、甚至 c.PostForm()（它内部会调用 ParseForm()）。
立即学习“go语言免费学习笔记（深入）”；
- 写法：
r.Body = http.MaxBytesReader(w, r.Body, 50（例如 50MB 总请求体） - 注意：这个值要包含所有文本字段 + 所有文件字节，不是单个文件上限
- Gin 中需手动获取
*http.Request：c.Request，再赋值给c.Request.Body - 别漏掉
w参数——它是http.ResponseWriter，用于写错误响应
Gin 中实际写法示例（含多文件总容量校验）
以下是一个生产可用的 handler 片段，兼顾硬拦截 + 业务层校验：
router.POST("/upload", func(c *gin.Context) {
// 第一层：硬拦截总请求体（含 headers + form fields + files）
c.Request.Body = http.MaxBytesReader(c.Writer, c.Request.Body, 50<<20) // 50MB
// 第二层：解析表单并校验总文件大小
if err := c.Request.ParseMultipartForm(32 << 20); err != nil {
c.String(http.StatusBadRequest, "form parse failed: %v", err)
return
}
// 累加所有文件 header.Size（注意：这是伪造风险点，仅作业务级二次校验）
var totalSize int64
if form, err := c.MultipartForm(); err == nil {
for _, files := range form.File {
for _, f := range files {
totalSize += f.Size
}
}
}
if totalSize > 20<<20 { // 业务要求总文件 ≤ 20MB
c.String(http.StatusBadRequest, "total file size exceeds 20MB")
return
}
// 正常处理上传...
})
关键点：
-
http.MaxBytesReader必须放在ParseMultipartForm之前，且不能有任何前置读取操作 ParseMultipartForm(32 的参数只是内存阈值，不影响 <code>MaxBytesReader行为- 多文件场景下，
form.File是 map[string][]*multipart.FileHeader，需双重遍历累加 - 每个
*multipart.FileHeader打开后记得defer file.Open().Close()，否则临时文件不清理
容易被忽略的坑：Gin 的中间件顺序和隐式读取
Gin 的 c.PostForm()、c.DefaultPostForm()、c.GetPostForm() 全部会触发 ParseForm()，而 ParseForm() 在 multipart 请求里会间接触发 ParseMultipartForm() —— 这意味着只要你在 MaxBytesReader 之后调了任意一个，就失效了。
- 不要在 handler 开头先取文本字段再设
MaxBytesReader - 自定义中间件若涉及读取 body（如日志、鉴权），必须确保它不提前消费
r.Body - 使用
c.Request.MultipartForm前务必确认MaxBytesReader已生效 - 测试时用 curl 发 chunked 请求或伪造超大
Content-Length，验证是否真被拦截
真正的防护链只有一次机会：body 第一次 Read 前。错过就只能靠 OS 层限流或反向代理（如 Nginx 的 client_max_body_size）兜底——但那已是边界防御，不该是应用层首选。
