go框架不自动限制请求体大小，必须显式使用http.maxbytesreader或http.maxbyteshandler；gin/echo的bodysizelimit配置本质是调用该函数，但仅在任何r.body读取操作前包装才生效，否则因中间件提前读取或绕过绑定而失效。
Go 框架本身不自动限制请求体大小，必须显式使用 http.MaxBytesReader 或 http.MaxBytesHandler，否则恶意大请求会直接耗尽内存或拖垮连接池。
为什么 Gin/Echo 的 BodySizeLimit 配置有时不起作用
框架的配置项（如 gin.SetMode()、e.MaxRequestBodySize）本质仍是调用 http.MaxBytesReader，但生效前提是：它必须在任何读取 r.Body 的操作之前完成包装。常见失效场景包括：
- 自定义中间件（如 JWT 验证）提前调用了
r.ParseForm()或io.ReadAll(r.Body)，导致原始r.Body已被读空，后续框架的包装无意义 - 业务 handler 中绕过
c.ShouldBindJSON()，直接用json.NewDecoder(c.Request.Body).Decode()，却没手动套http.MaxBytesReader - 使用了
gin.DefaultWriter但没确认其底层是否已启用限流（v1.9+ 默认启用，但自定义gin.Engine实例时可能被覆盖）
ParseMultipartForm 的 maxMemory 参数不是总大小限制
r.ParseMultipartForm(maxMemory) 只控制「内存中缓存的表单数据量」，超出部分会写入临时文件——它不限制总上传体积。攻击者可发一个 100MB 文件 + 1KB 表单字段，maxMemory = 32 完全拦不住。
真正有效的组合是：
- 先用
r.Body = http.MaxBytesReader(w, r.Body, 50 限制总上传量（如 50MB） - 再调
r.ParseMultipartForm(8 ，设较小的 <code>maxMemory（如 8MB），让小文件走内存、大文件落盘，但总大小已被前置限制卡死 - 最后用
r.FormFile("file")获取磁盘句柄，而非r.FormValue()（后者只读文本字段）
全局 vs 路由级限流：选 MaxBytesHandler 还是 MaxBytesReader
http.MaxBytesHandler 包裹整个 http.Handler，在请求进入任何路由前就拦截超限请求，返回 413 并关闭连接，最安全、不易遗漏；但它无法区分接口语义——登录接口和上传接口被迫共用同一上限。
http.MaxBytesReader 是 per-handler 控制，需每个 handler 开头手动赋值：r.Body = http.MaxBytesReader(w, r.Body, limit)。它灵活，但容易漏写或顺序错。
推荐策略：
- 所有接口统一宽松上限（如 10MB）→ 直接用
http.MaxBytesHandler - 需要差异化（如
/login限 2MB，/upload限 100MB）→ 用MaxBytesReader，并在中间件里做路由匹配后动态赋值 - 无论哪种，都必须配合
http.Server.ReadTimeout和MaxHeaderBytes，否则慢速攻击或超长 header 仍可绕过 body 限制
最容易被忽略的一点：http.MaxBytesReader 在超限时会设置 w.(*response).reqbodylimithit = true，触发服务器自动关闭 TCP 连接——但这依赖 handler 正常返回。如果 handler 里有死循环、阻塞 channel 或 panic 未捕获，连接可能卡住不释放。务必确保 handler 有兜底超时和错误处理。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
