c.multipartform()会卡住或内存爆满，因其默认将整个multipart body读入内存解析；需改用c.request().multipartreader()流式处理，并提前调用parsemultipartform()设定内存上限。
为什么 c.MultipartForm() 会卡住或内存爆满
直接调用 c.MultipartForm() 处理大文件时，Echo 默认会把整个 multipart body 全部读入内存，再解析成 *multipart.Form。几十 MB 就可能触发 OOM，上百 MB 基本必然崩溃，且无进度反馈、无法中断。
根本原因在于：Echo 的默认绑定器对 multipart/form-data 没做流式处理，而是走完整体解析路径。这不是 bug，是设计取舍——它优先保证小表单的简洁性，不默认承担大文件的复杂性。
- 必须绕过
c.MultipartForm()和c.FormValue()，改用c.Request().MultipartReader() - 不要用
c.File()（该方法内部仍依赖MultipartForm） - 上传前需在路由 handler 中显式调用
c.Request().ParseMultipartForm(32 设置最大内存阈值（如 32MB），否则默认仅 32KB，超限直接返回 <code>http.ErrMissingBoundary
如何用 io.Copy + LimitReader 安全接收分片
分片上传的核心是「不落地、不全读、可控流」。你需要手动从 MultipartReader 中提取每个 *multipart.Part，再逐块写入磁盘或对象存储。
关键点不是“怎么分”，而是“怎么接”——尤其要防恶意构造的超长字段或无限数据流。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 对每个
part，先检查part.Header.Get("Content-Disposition")是否含filename=，过滤掉纯表单字段 - 用
http.MaxBytesReader(c.Response(), part, 100 包裹 <code>part，限制单个分片最大 100MB，避免攻击者发一个超大伪造分片耗尽内存 - 写入磁盘时用
os.O_CREATE | os.O_WRONLY | os.O_APPEND打开文件，确保多 goroutine 并发写同一文件不覆盖（前提是分片按序号写） - 别用
io.Copy直接灌到底——加一层io.LimitReader(part, maxChunkSize)，和前端约定好每片 ≤5MB，便于校验与重传
X-Upload-ID 和 Upload-Offset 怎么配合实现断点续传
Echo 本身不提供上传 ID 管理或偏移跟踪，这部分必须自己维护。常见做法是：前端每次上传分片时带 X-Upload-ID（UUID）和 Upload-Offset（当前分片起始字节），后端根据 ID 查当前已写入总长度，比对 offset 判断是否重复/跳片/乱序。
这个逻辑不能只靠内存 map，线上必须持久化（哪怕只是本地 SQLite 或 Redis）。否则服务重启，所有上传状态丢失，用户只能重来。
- 收到分片前，先查 DB：SELECT
uploaded_sizeFROMuploadsWHEREupload_id = ?，若不存在则 INSERT 新记录 - 比对
Upload-Offset和查出的uploaded_size，不等就返回 409 Conflict（表示客户端状态错乱） - 写完当前分片后，UPDATE
uploaded_size = uploaded_size + chunk_size，并记录分片 hash（用于最终合并前校验） - 合并操作（所有分片收齐后）应异步触发，避免阻塞 HTTP 请求；可用
time.AfterFunc或简单 channel 转发到 worker goroutine
合并分片时 os.Rename 失败的真正原因
最后一步把临时分片文件拼成完整文件，很多人用 os.Create + 多次 io.Copy，但更高效的是用 os.OpenFile 以 os.O_CREATE|os.O_WRONLY|os.O_APPEND 模式打开目标文件，然后按分片顺序 io.Copy 进去。但要注意：os.Rename 在跨文件系统时会失败（比如 /tmp 和 /data 不在同一 mount point），而很多 Docker 部署恰好如此。
这不是权限问题，是 syscall.ENOTSUP 错误。此时必须 fallback 到 copy + remove，不能硬 rename。
- 合并前先
os.Stat(dst)，再os.Stat(src)，对比Stat.Sys().(*syscall.Stat_t).Dev是否一致 - 不一致就用
io.Copy+os.Remove，一致才用os.Rename - 合并完成后，务必校验最终文件 size 和所有分片 size 总和是否相等——网络传输中丢包或截断不会报错，只会让文件变短
