go框架需显式用http.maxbytesreader限制请求体大小，且必须在parseform等读取操作前调用，否则失效；multipart场景需maxbytesreader与parsemultipartform协同，并清理临时文件。
Go 框架本身不自动限制请求体大小，必须显式使用 http.MaxBytesReader 或 http.MaxBytesHandler，否则恶意大请求会直接耗尽内存或拖垮连接池。
为什么 MaxBytesReader 必须在 ParseForm 前调用
http.MaxBytesReader 不是“设个开关就生效”的拦截器，它只在第一次调用 r.Body.Read()（包括 r.ParseForm()、json.NewDecoder(r.Body).Decode()、io.ReadAll(r.Body)）时才开始计数并拦截。一旦这些操作先于包装发生，Body 就可能已被部分或全部读进内存，后续再套 MaxBytesReader 就等于没设。
- 常见错误现象：
panic: runtime: out of memory、服务响应变慢但日志无报错、http: TLS handshake error伴随连接堆积 - 正确顺序只能是：handler 第一行代码就执行
r.Body = http.MaxBytesReader(w, r.Body, limit) - 之后才能调用
r.ParseForm()、r.FormValue()、json.Decode()等任何触发读取的操作 - 如果你用了中间件（如 JWT 验证），确保它不调用
io.ReadAll(r.Body)或r.ParseForm()——否则限制在进入业务 handler 前就已失效
Gin/Echo 的 BodySizeLimit 配置为何有时无效
框架的配置项（如 gin.DefaultWriter、e.MaxRequestBodySize）本质仍是调用 http.MaxBytesReader，但生效前提是：它必须在任何读取 r.Body 的操作之前完成包装。
- 常见失效场景包括：自定义中间件提前调用了
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实例时可能被覆盖） - 不要假设“用了框架就万事大吉”——检查你是否在中间件或自定义解析逻辑中提前读了
Body
ParseMultipartForm 的 maxMemory 参数不是总大小限制
r.ParseMultipartForm(maxMemory) 只控制「内存中缓存的表单数据量」，超出部分会写入临时文件——它不限制总上传体积。攻击者可发一个 100MB 文件 + 1KB 表单字段，maxMemory = 32 完全拦不住。
- 真正有效的组合是：先用
r.Body = http.MaxBytesReader(w, r.Body, 50 * 1024 * 1024)限制总上传量（如 50MB） - 再调
r.ParseMultipartForm(8 * 1024 * 1024)，设较小的maxMemory（如 8MB），让小文件走内存、大文件落盘，但总大小已被前置限制卡死 - 最后用
r.FormFile("file")获取磁盘句柄，而非r.FormValue()（后者只读文本字段） -
Content-Length不可靠：HTTP/1.1 允许 chunked 编码，该头可能为 -1，无法反映真实负载长度
全局 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和http.Server.MaxHeaderBytes，否则头部膨胀或慢速读取仍可绕过 Body 限制
最容易被忽略的点是：限流必须在任何 Body 读取动作之前生效，而 multipart 场景下仅靠总大小限制并不足够——maxMemory 和 MaxBytesReader 必须协同使用，且临时文件路径需有清理机制，否则磁盘会被悄悄打满。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
