gin 的 maxrequestbodysize 有时不生效，根本原因是其底层 http.maxbytesreader 仅在 r.body.read() 首次调用时开始计数；若中间件提前读取 r.body（如 parseform、io.readall 等），则限流失效，导致内存暴涨、oom 或 tls 握手错误；可靠做法是在 handler 开头第一行手动包装 r.body = http.maxbytesreader(w, r.body, limit)，并自行捕获 http.errbodytoolarge 返回 413。
为什么 Gin 的 MaxRequestBodySize 有时完全不生效
根本原因不是配置写错了，而是 MaxRequestBodySize 本质是调用 http.MaxBytesReader，而它只在 r.Body.Read() 第一次被调用时才开始计数——如果中间件或业务逻辑提前读了 r.Body（比如 JWT 中间件调了 r.ParseForm() 或 io.ReadAll(r.Body)），那原始 Body 就已被消费，后续再包装也无效。
常见现象包括：服务内存暴涨、panic: runtime: out of memory、大量 http: TLS handshake error 日志伴随连接堆积，但 Gin 日志里却看不到请求记录——说明请求在进入路由前就被卡死了，或者 Body 已悄悄进内存。
- 检查所有自定义中间件，禁止任何对
r.Body的直接读取操作（ParseForm、ParseMultipartForm、io.ReadAll、json.NewDecoder(r.Body).Decode()都算） - Gin v1.9+ 默认启用限流，但如果你手动创建了
gin.Engine实例（比如绕过gin.Default()），要确认没覆盖gin.DefaultWriter或禁用底层包装 -
c.ShouldBindJSON()内部会触发r.Body.Read()，所以限流必须在它之前完成；若你绕过绑定、直接用json.NewDecoder(c.Request.Body).Decode()，就得自己套http.MaxBytesReader
如何在 handler 中手动加限流才真正可靠
最可控的方式，是在每个需要防护的 handler 开头第一行就执行 r.Body = http.MaxBytesReader(w, r.Body, limit)。这不是“多此一举”，而是绕过框架封装不确定性、确保限制绝对生效的唯一办法。
注意：http.MaxBytesReader 不会自动返回 413，它只让后续 Read() 操作返回 http.ErrBodyTooLarge，你得自己捕获并响应。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 示例：上传接口限制 50MB
r.Body = http.MaxBytesReader(w, r.Body, 50- 紧接着调
r.ParseMultipartForm(8 （<code>maxMemory设小点，让小字段走内存、大文件落盘） - 然后用
r.FormFile("file")获取文件句柄，别用r.FormValue()处理大字段 - 遇到
http.ErrBodyTooLarge时，必须显式调http.Error(w, "...", http.StatusRequestEntityTooLarge)
ParseMultipartForm 的 maxMemory 参数不是总大小限制
这是最常被误解的一点：r.ParseMultipartForm(maxMemory) 只控制「存入内存的表单数据量」，超出部分自动写入临时磁盘文件——它不限制整个请求体总大小。攻击者可以构造一个 1KB 表单 + 99MB 文件的请求，只要总大小没超限，maxMemory 完全拦不住。
真正有效的组合是：前置总大小限制 + 后置内存缓冲控制。
- 先用
http.MaxBytesReader卡死总上传体积（如 50MB） - 再设较小的
maxMemory（如 8MB），让小字段进内存、大文件走磁盘 - 最后通过
r.FormFile()拿到的是磁盘上的*os.File，不是内存里的字节流 - 记得清理临时文件：
defer os.Remove(tempFile.Name())或使用io.Copy后手动Close()
全局限流用 MaxBytesHandler 还是 per-handler MaxBytesReader
http.MaxBytesHandler 包裹整个 http.Handler，在请求刚进入服务器时就拦截超限请求，返回 413 并立即关闭连接，最安全、不易遗漏；但它无法区分接口语义——登录接口和上传接口被迫共用同一上限。
http.MaxBytesReader 更灵活，可按路由、按 handler 精细控制（比如上传接口 50MB，API 接口 2MB），但要求你每个 handler 都手动处理，且必须严格保证顺序。
- 若服务全是统一规格接口（如纯 REST API），优先用
MaxBytesHandler，一劳永逸 - 若存在混合场景（如
/api/login和/api/upload），必须用 per-handlerMaxBytesReader，否则上传接口的宽松限制会拖垮其他接口 - 别忘了 Nginx 层的
client_max_body_size，它比 Go 层更早拦截；值必须 ≥ Go 层设置，否则请求根本到不了你的 handler
maxMemory 能防大文件，结果它只管内存部分；你以为限流设了就完事，结果反向代理先一步把请求拦掉了——这些断层，才是线上出问题的真正源头。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
