Gin 本身不提供带宽限速中间件，MaxMultipartMemory 仅限制内存缓冲而非网络速率；可行方案是用中间件替换 c.Request.Body 为 io.LimitReader 包装器，在读取前实施速率控制。
直接说结论：Gin 本身不提供带宽限速中间件，也无法靠 MaxMultipartMemory 控制上传带宽；真正可行的方案是用 HTTP 中间件劫持 ResponseWriter + io.LimitReader 或自定义 http.ResponseWriter 包装器，在写入响应前对请求体流做速率节制——但注意，这仅对「服务端主动读取请求体」的场景有效，且必须在 c.Request.Body 被消费前介入。
为什么 router.MaxMultipartMemory 对带宽无效
这个字段只控制 Gin 解析 multipart 表单时允许使用的内存上限（默认 32MB），它不干预网络层传输速度，也不限制磁盘写入速率。即使设为 1（约 8MiB），大文件仍会经由底层 net/http 流式写入临时磁盘，客户端该多快还是多快，服务器只是“更早报错”或“换地方存”，而非“限速”。你看到的“不起作用”，本质是混淆了「内存缓冲限制」和「带宽控制」两个维度。
-
MaxMultipartMemory影响的是c.FormFile()和c.MultipartForm()的可用性，不是 TCP 层限速 - 真正卡住或超时，往往来自
http.Server.ReadTimeout/WriteTimeout，而非 Gin 配置 - 若想让上传变慢，得在读请求体时人为加 delay，或用
io.LimitReader包装c.Request.Body
如何用中间件对单个请求做上传带宽限制
核心思路是：在 handler 执行前，把 c.Request.Body 替换为一个带速率限制的 reader。Gin 允许你安全地替换它，只要确保没被其他中间件提前读过（比如 c.PostForm 或 c.FormFile 已调用，就晚了）。
- 先调
c.Request.ParseMultipartForm(32 （仅解析头部，不读 body）避免后续 <code>c.FormFile冲突 - 用
io.LimitReader(c.Request.Body, maxBytes)只能限总量，不能限速率；要限速率，得用golang.org/x/time/rate.Limiter+ 自定义io.Reader - 推荐封装一个
RateLimitedReader，每次Read(p []byte)前调limiter.WaitN(ctx, len(p))，再转发读操作 - 中间件里替换 body 后，记得用
c.Request.Body = newReader，并 deferc.Request.Body.Close() - 别在多个中间件里重复替换
Body，否则会 panic：「body already read」
实际部署时最常踩的坑
带宽限速中间件看似简单，落地时几乎必踩三个硬伤：
- 认证中间件（如 JWT）若调用了
c.ShouldBindJSON或c.PostForm，会提前消费Body，导致你的限速 reader 拿到空流——必须确保限速中间件在所有「读 body」操作之前 - 前端用
fetch或XMLHttpRequest上传时，若未设置timeout，客户端可能等几分钟才报错，用户感知是「卡死」而非「限速」 - Linux 系统级
net.core.wmem_max和rmem_max会影响 TCP 缓冲区行为，单纯 Go 层限速可能被底层绕过，建议配合iptables或负载均衡器（如 Nginx 的limit_rate）做兜底 - 并发上传场景下，每个请求独立限速，但总带宽仍可能打满网卡——这不是中间件问题，是架构层面需考虑的资源隔离
真正需要带宽控制的场景（比如 SaaS 多租户上传配额），光靠 Gin 中间件不够稳健。优先在反向代理层（Nginx、Traefik）做 limit_rate，Gin 层只负责业务逻辑和错误透传；若必须在 Go 层控，务必把限速 reader 的初始化和 Body 替换时机卡死在第一个中间件，并全程避免任何隐式读 body 的调用。
