router.MaxMultipartMemory 在网关层失效，因其仅限制内存缓冲（默认32MiB），不校验Content-Length，无法在读取body前拦截超大请求；应使用http.MaxBytesReader中间件在ParseMultipartForm前强制限制总上传大小。
为什么 router.MaxMultipartMemory 在网关层失效
微服务网关（如基于 Gin 自研的 API 网关）本身不直接处理业务文件逻辑，但常被期望提前拦截超大上传请求。问题在于：router.MaxMultipartMemory 只控制 Gin 解析 multipart 表单时的内存缓冲上限，默认 32 MiB；它**不拒绝请求体本身**，更不校验 Content-Length。当客户端发来一个 500MB 的 multipart/form-data 请求时，Gin 会把前 32MB 读进内存，其余自动落盘到临时文件（/tmp/xxx），等你调用 c.FormFile() 时才报错——此时请求早已穿透网关、占用大量 I/O 和磁盘，失去“拦截”意义。
必须在读取 body 前就限制总长度
真正有效的拦截点是 HTTP 请求头里的 Content-Length，且必须在 Gin 调用 c.Request.ParseMultipartForm() 之前完成判断。推荐用中间件 + http.MaxBytesReader：
- 在网关路由注册前插入中间件，对所有
POST/PUT且Content-Type含multipart/form-data的请求生效 - 用
http.MaxBytesReader(c.Writer, c.Request.Body, maxUploadSize)包裹原始Body，其中maxUploadSize是你允许的最大字节数（例如10 表示 10MB） - 务必在中间件里重置
c.Request.Body，否则后续 handler 拿不到数据 - 若超出限制，
http.MaxBytesReader会在第一次Read()时返回http.ErrBodyReadAfterClose或类似错误，此时应立即c.AbortWithStatus(http.StatusRequestEntityTooLarge)
示例关键代码：
func LimitUploadSize(maxSize int64) gin.HandlerFunc {
return func(c *gin.Context) {
ct := c.GetHeader("Content-Type")
if strings.Contains(ct, "multipart/form-data") && c.Request.Method == "POST" {
// 检查 Content-Length 头（虽可伪造，但多数正规客户端会带）
if cl := c.GetHeader("Content-Length"); cl != "" {
if size, err := strconv.ParseInt(cl, 10, 64); err == nil && size > maxSize {
c.AbortWithStatus(http.StatusRequestEntityTooLarge)
return
}
}
// 即使没 Content-Length，也用 MaxBytesReader 强制限制
c.Request.Body = http.MaxBytesReader(c.Writer, c.Request.Body, maxSize)
}
}
}
// 使用
r := gin.Default()
r.Use(LimitUploadSize(10 << 20)) // 全局限制 10MB
r.POST("/upload", uploadHandler)
网关层无法校验分片上传字段，别试图解析 multipart
如果你的后端服务支持分片上传（比如接收 chunkNumber、identifier 字段），网关**绝不应该调用 c.FormValue() 或 c.MultipartForm()**。原因有三：
- 调用这些方法会触发 Gin 完整解析 multipart body，导致网关提前消耗内存或磁盘，违背轻量转发原则
- 分片协议（如 tus、custom chunking）没有标准字段名，前端可能传
upload_id或fileId，网关硬解析等于耦合业务逻辑 - 分片请求通常不带完整文件内容，
Content-Length很小，单纯靠大小限制无法区分“合法分片”和“恶意小包刷接口”
正确做法：只放行已知分片上传路径（如 /api/v1/upload/chunk），并信任下游服务自己的分片校验逻辑；网关只做总量级拦截（如单请求 ≤ 10MB），不碰字段语义。
注意临时目录和并发写冲突的实际影响
即使你在网关用了 http.MaxBytesReader，Gin 在解析失败后仍可能留下未清理的临时文件（尤其当请求中断时）。这些文件默认落在系统 /tmp 下，由 Go 的 os.TempDir() 决定，**不会受你设置的 router.MaxMultipartMemory 影响**。长期运行的网关容易因磁盘占满崩溃。
缓解方式：
- 启动时指定环境变量
GOTMPDIR=/var/tmp/gin-gateway，让所有临时文件集中管理 - 配合 systemd 或 cron 定期清理该目录下超过 5 分钟的
multipart-*文件 - 避免在网关中调用
c.SaveUploadedFile()或任何触发文件落盘的操作——那是下游服务的事
最易被忽略的一点：网关通常部署多实例，但临时文件清理必须是单机行为；如果用分布式锁或共享存储清理，反而引入新复杂度。务实做法是接受单机清理，并监控 df -h /var/tmp。
