gin.setmode(gin.releasemode) 不能解决请求体超限问题，因其仅控制日志和错误提示级别，不设任何请求体大小限制；gin 默认不限制请求体，需显式设置 r.maxmultipartmemory（multipart场景）或使用 http.maxbytesreader（通用场景）来防止 oom。
为什么 gin.SetMode(gin.ReleaseMode) 不能解决请求体超限问题
很多人误以为切换到 Release 模式就能自动处理大请求，其实它只影响日志和错误提示的详细程度，跟请求体大小限制完全无关。Gin 默认对请求体没有硬性上限，http.Request.Body 会一直读取直到 EOF，遇到几百 MB 的上传或恶意构造的超长 JSON，进程可能 OOM 或被拖慢。
正确设置请求体上限：用 gin.Default() + r.MaxMultipartMemory
Gin 的 gin.Default() 返回的引擎默认使用 http.Server，但真正控制 multipart 表单（含文件上传）内存上限的是 r.MaxMultipartMemory 字段；对纯 JSON/文本请求，则依赖底层 http.Server.MaxHeaderBytes 和读取逻辑。实际要分两步：
-
r := gin.Default()后立即设置r.MaxMultipartMemory = 8 ，否则 multipart 解析时可能 panic - 对非 multipart 请求（如
application/json），需在http.Server层加限制：用http.Server的MaxRequestBodySize（Go 1.19+）或手动中间件拦截 - 注意：
r.MaxMultipartMemory单位是字节，不是 MB，写成8 * 1024 * 1024或8 更安全，避免整数溢出
手动中间件拦截超大 JSON 请求体的典型写法
Go 标准库不提供全局请求体大小限制，所以对 application/json 这类非 multipart 类型，必须自己写中间件。关键点是：不能等 c.ShouldBindJSON() 再检查，那时 Body 已被读完、无法重置。
- 用
c.Request.Body包一层io.LimitReader，例如c.Request.Body = http.MaxBytesReader(c.Writer, c.Request.Body, 2 - 必须在所有路由注册前使用
r.Use()注册该中间件，否则部分 handler 可能绕过 - 如果用了
gin.Recovery()，确保限流中间件在它之前，否则 panic 可能掩盖http.ErrBodyTooLarge - 返回错误时用
c.AbortWithStatusJSON(http.StatusRequestEntityTooLarge, ...)，别用c.String()，避免 Content-Type 不匹配
常见错误现象与调试线索
请求体超限后表现往往不统一：有时返回 413，有时连接直接关闭，有时服务卡死——这取决于触发的是标准 HTTP 错误、Gin panic 还是系统 OOM Kill。
- 看到
http: request body too large日志，说明http.MaxBytesReader生效了 - 出现
runtime: out of memory或panic: multipart: Part.Read: http: request body too large，说明r.MaxMultipartMemory没设或设得太小 - curl 测试时加
-v看响应头，确认是否返回413 Request Entity Too Large，而不是 500 或超时 - 用
curl -X POST -H "Content-Type: application/json" --data-binary @huge.json http://localhost:8080/api验证，别只测小数据
真正麻烦的是 multipart 和 JSON 混合场景：比如一个接口既收 JSON 字段又收文件，这时 r.MaxMultipartMemory 控制整体，但 JSON 解析仍可能单独触发内存暴涨——得靠 io.LimitReader 兜底，且顺序不能错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
