不能直接用 r.Run() 部署，因其内部使用默认 http.Server，未设置 MaxMultipartMemory、ReadBufferSize 等关键参数，导致上传文件无内存上限、JSON body 可无限长、header 大小无约束，易引发 OOM 或服务崩溃。
生产环境部署 Gin 时，r.Run() 直接启动 HTTP 服务不满足安全与资源控制要求，必须显式配置 http.Server 并设置 MaxMultipartMemory 和 ReadBufferSize 等关键参数，否则默认限制（如 32MB multipart、无 body 读取上限）极易引发 OOM 或被恶意请求拖垮。
为什么不能直接用 r.Run() 部署
r.Run() 内部使用默认 http.Server，未设任何请求边界：上传文件无内存上限、JSON body 可无限长、header 大小无约束。线上服务一旦遭遇构造的超大 payload（比如 500MB 的 base64 图片字段），进程会迅速耗尽内存并 panic。
常见错误现象包括：
- 服务突然卡死或频繁重启，
dmesg显示Out of memory: Kill process -
curl -X POST -H "Content-Type: application/json" --data-binary @huge.json导致 goroutine 阻塞数分钟 - 上传接口返回
400 Bad Request但日志无明确原因，实为 multipart 解析阶段内存超限
http.Server 必须设置的 3 个请求限制参数
替换 r.Run() 为手动构建 http.Server，以下参数不可省略：
-
MaxMultipartMemory：限制 multipart 表单（含文件上传）最大内存用量，单位字节。建议设为32 （32MB），超出部分写入临时磁盘（需确保 <code>os.TempDir()可写） -
ReadBufferSize：限制单次Read()调用最大字节数，影响 header 和 body 初始读取。设为4096（4KB）可防超长 header 攻击 -
MaxHeaderBytes：硬性限制 header 总大小，防止Cookie或Authorization字段膨胀。建议1 （1MB）以内，多数场景 64KB 足够
示例代码片段：
srv := &http.Server{
Addr: ":8080",
Handler: r,
ReadBufferSize: 4096,
MaxHeaderBytes: 1 << 20,
}
srv.SetKeepAlivesEnabled(true)
// 注意：MaxMultipartMemory 需在路由处理前设置，通过 gin 的 Bind 方法间接控制
// 实际生效靠 c.Request.MultipartReader() 时的底层 http.MaxBytesReader 包装
如何对 JSON/FORM 请求做精确大小拦截
Gin 不提供全局 body 大小钩子，必须在中间件中手动读取并校验。关键点：
- 不能用
c.GetRawData()—— 它会消耗原始 body，后续绑定失效 - 应使用
c.Request.Body的io.LimitReader包装，再交还给 Gin 绑定流程 - 对
application/json和application/x-www-form-urlencoded分别处理
推荐中间件写法：
func LimitBodySize(max int64) gin.HandlerFunc {
return func(c *gin.Context) {
if c.Request.Method == "GET" || c.Request.Method == "HEAD" {
return
}
contentLength := c.Request.ContentLength
if contentLength == -1 || contentLength > max {
c.AbortWithStatusJSON(http.StatusRequestEntityTooLarge, gin.H{"error": "request too large"})
return
}
// 对于 multipart，gin 已通过 MaxMultipartMemory 控制；其余类型可信任 Content-Length
// 若需更严格（如忽略 Content-Length），则用 LimitReader 包装 Body
if c.GetHeader("Content-Type") == "application/json" {
c.Request.Body = http.MaxBytesReader(c.Writer, c.Request.Body, max)
}
}
}
// 使用：r.Use(LimitBodySize(2 << 20)) // 2MB
部署时容易被忽略的 2 个硬性约束
即使代码层做了限制，反向代理和操作系统仍可能截断请求：
- Nginx 默认
client_max_body_size 1m，若后端允许 32MB，Nginx 会先返回413 Request Entity Too Large。需同步配置：client_max_body_size 32m; - Linux
net.core.rmem_max和net.core.wmem_max影响 TCP 缓冲区，极端高并发下小 buffer 会导致连接重传甚至超时，建议调至262144（256KB）以上
这些不是 Gin 框架能控制的，但漏掉任何一个，前面所有代码限制都形同虚设。
