beego默认文件上传不适用于大文件，因其getfile/savetofile依赖parsemultipartform，会一次性读入内存或临时磁盘，导致阻塞、超时、无断点续传且无法恢复中断。
Beego 本身不内置分片上传/下载逻辑，必须自己实现分片协调、合并、断点续传等能力；直接用 GetFile 或 SaveToFile 处理大文件会阻塞请求、耗尽内存、触发超时，且无法恢复中断。
为什么 Beego 的默认文件上传不适用于大文件
Beego 的 GetFile 和 SaveToFile 底层调用的是 http.Request.ParseMultipartForm，它会将整个 multipart body 一次性读入内存（或临时磁盘），并解析全部字段和文件。这意味着：
- 上传 500MB 文件时，Beego 默认会尝试分配至少 500MB 内存缓冲区（受
MaxMemory控制） - 若未显式设置
MaxMemory，默认值为 32MB，超限后直接返回http: request body too large - 即使设为 0（强制写临时文件），整个上传过程仍是一次性阻塞式 IO，无进度反馈、无校验、无分片控制
- 客户端一旦断开，服务端无法感知中间状态，也无法恢复续传
分片上传：前端传 hash + chunk + index，后端用临时目录拼接
核心思路是绕过 Beego 的文件解析封装，直接从 this.Ctx.Request.Body 读原始流，并按约定协议提取分片元数据（如 X-File-Name、X-Chunk-Index、X-Total-Chunks、X-File-Hash）。示例关键步骤：
- 在 controller 中禁用自动 multipart 解析：
this.Ctx.Input.DelStaticPath()并确保路由未被静态文件中间件拦截 - 手动读取 raw body：
body, _ := io.ReadAll(this.Ctx.Request.Body)（仅用于小分片；大分片建议io.Copy到临时文件） - 按分片信息生成唯一临时路径，例如：
/tmp/uploads/{file_hash}/{chunk_index} - 所有分片接收完毕后，按
index顺序 cat 合并：cat /tmp/uploads/abc123/* > /data/uploads/final.zip - 务必校验最终文件 hash，防止拼接错乱或传输损坏
分片下载：用 http.ServeContent 实现 Range 支持
Beego 的 Ctx.ResponseWriter 是标准 http.ResponseWriter，可直接对接 Go 原生流式响应。要支持断点续传下载，不能用 Output.Data 全量写入，而应：
- 设置正确 header：
this.Ctx.Output.Header("Accept-Ranges", "bytes") - 获取 Range 请求头：
rangeHeader := this.Ctx.Request.Header.Get("Range") - 打开文件，seek 到指定 offset，用
http.ServeContent包装响应（需提供modtime和size） - 注意：Beego 默认会写
Content-Length，若手动处理 Range，需先清空：this.Ctx.ResponseWriter.WriteHeader(http.StatusPartialContent)，再调用http.ServeContent
容易忽略的三个硬伤
实际部署时最常翻车的不是逻辑，而是基础设施约束：
- Nginx 默认
client_max_body_size 1m，必须显式调大（如client_max_body_size 2G），且要同步改proxy_buffering off避免缓存分片 - Beego 的
MaxMemory必须设为 0（禁用内存缓冲），否则分片请求仍可能被 multipart 解析器提前拒绝 - 临时分片目录需有独立磁盘空间和清理机制（比如用
tmpfs或定时find /tmp/uploads -mmin +60 -delete），否则磁盘爆满静默失败
