iris.UploadMaxMemory 是控制内存缓冲上限的关键配置，单位字节，超过则 ctx.ReadForm 或 ctx.FormFile 直接返回 http.ErrRequestEntityTooLarge；默认值为 32。
iris.UploadMaxMemory 是控制内存缓冲上限的关键配置
上传文件时，Iris 默认会把整个请求体读入内存做初步解析，UploadMaxMemory 就是这个内存缓冲区的大小上限（单位字节）。超过它，ctx.ReadForm 或 ctx.FormFile 会直接返回 http.ErrRequestEntityTooLarge 错误，而不是等到写入磁盘才失败。
它不等于最终文件大小限制，但它是第一道防线——尤其对小文件或表单字段混合上传场景，必须设好。
-
UploadMaxMemory默认值是32 （即 32MB），对多数 API 已偏大 - 设为
0表示不限制内存缓冲，风险极高，不建议 - 设为负数（如
-1）会被 Iris 忽略，退回到默认值 - 该值只影响
ctx.ReadForm和ctx.FormFile，不影响ctx.Request.Body的原始流读取
真正限制文件体积得靠 ctx.ReadForm 的 maxMemory 参数
ctx.ReadForm 是处理 multipart/form-data 的核心方法，它的第二个参数 maxMemory 才是决定「多大文件能进内存」的实际阈值。这个值优先级高于全局 UploadMaxMemory，且必须显式传入。
如果你没调用 ctx.ReadForm，而是直接用 ctx.FormFile，Iris 内部仍会先调用 ReadForm，此时就用你配置的 UploadMaxMemory 值。
- 推荐写法：
err := ctx.ReadForm(32 —— 显式限定 32MB - 若想支持超大文件（如 >100MB），应传
0，然后手动从ctx.Request.Body流式读取，绕过内存缓冲 - 注意：即使
maxMemory = 0，ctx.FormValue等表单字段仍可用，Iris 会把非文件字段先解析出来
HTTP 层还需配合反向代理（如 Nginx）的 client_max_body_size
Iris 自身无法拦截 TCP 层或反向代理层的请求截断。如果前端请求先经过 Nginx，而 Nginx 的 client_max_body_size 设为 1MB，那么哪怕 Iris 配了 100MB，请求根本到不了 Go 进程，用户只会收到 413 Request Entity Too Large。
- Nginx 配置示例：
client_max_body_size 50M;，需放在http、server或location块中 - Cloudflare、ALB 等托管服务也有类似限制，需单独检查并调大
- Iris 日志里看不到这类 413 错误，因为请求被代理拦下了，这点极易误判为框架问题
大文件上传应放弃 FormFile，改用流式处理
当文件可能超过几十 MB 时，硬扛在内存里既危险又低效。正确做法是跳过 ctx.FormFile，直接操作原始 body 流，并结合分片、校验、临时存储等逻辑。
- 调用
ctx.Request.ParseMultipartForm(0)避免自动解析（否则仍会触发UploadMaxMemory） - 用
multipart.NewReader(ctx.Request.Body, boundary)手动遍历每个 part - 对 file part，用
io.Copy直接写入磁盘或对象存储，不经过内存缓冲 - 务必设置
ctx.Request.Header.Set("Connection", "keep-alive")防止长传被代理中断
UploadMaxMemory、ReadForm 调用时的 maxMemory 参数、以及最外层反向代理的 body 大小限制。少配任何一环，上传边界就会出人意料地失效。 
