直接用Echo的context.FormFile处理大文件会失败，因其底层调用http.Request.ParseMultipartForm，默认maxMemory=32MB，超限文件落磁盘但全程不响应超时，易致OOM或413错误。
为什么直接用 context.FormFile 会失败
大文件上传时，Echo 默认的 context.FormFile 会把整个 multipart body 读进内存，触发 OOM 或超时。尤其当单个文件超 100MB、并发稍高时，服务直接卡死或返回 413 Request Entity Too Large。这不是 Echo 的 bug，而是标准 http.Request.ParseMultipartForm 的行为——它默认将文件暂存到内存（maxMemory=32），超出才写磁盘，但 Echo 没暴露这个参数入口。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 禁用
c.FormFile，改用c.MultipartForm()手动解析，控制读取流 - 在
echo.HTTPErrorHandler中捕获http.ErrBodyReadAfterClose和io.ErrUnexpectedEOF，避免 panic 泄露 - 启动前调大 HTTP server 的
ReadTimeout和MaxHeaderBytes，例如设为30 * time.Minute
分片上传必须校验 upload_id 和 chunk_index
前端传来的每个分片需带唯一标识（如 UUID）和顺序索引，否则合并时无法保证完整性。常见错误是只用文件名做 key，导致同名文件并发上传时覆盖临时块；或用毫秒时间戳作序号，网络延迟造成乱序写入。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 服务端生成
upload_id（如uuid.NewString()），返回给前端，后续所有分片请求必须携带该 ID -
chunk_index必须是整数且从 0 开始，后端收到后立即校验是否>= 0且，不满足则拒收 - 临时分片存到磁盘时，路径格式固定为：
/tmp/uploads/{upload_id}/{chunk_index}，避免路径遍历（对upload_id做白名单校验，只允许字母、数字、下划线）
合并阶段用 os.OpenFile + io.Copy 而非 os.Rename
有人试图把第一个分片直接 Rename 成目标文件，再用 os.WriteFile 追加后续分片——这会导致数据错位。因为分片是按原始文件切分的，不是按字节流顺序追加，而是按偏移写入指定位置。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 合并前先创建空目标文件：
f, _ := os.OpenFile(destPath, os.O_CREATE|os.O_WRONLY, 0644) - 遍历
0..total_chunks-1，按序打开每个分片文件，计算写入偏移：f.Seek(int64(chunkSize)*int64(i), 0) - 用
io.Copy写入，而非io.ReadFull——后者在分片末尾不齐时会报io.ErrUnexpectedEOF - 合并完成后，用
sha256.Sum256校验最终文件 hash，与前端传来的file_hash对比，不一致则删掉目标文件并返回错误
临时分片清理不能依赖定时任务
靠 cron 每小时扫一遍 /tmp/uploads 删除 24 小时前的目录，会漏掉上传中断但未完成的分片（比如用户关浏览器），也容易误删正在上传中的活跃分片。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个分片写入时，同时写一个
.meta文件（JSON 格式），含upload_id、created_at、total_chunks、received_chunks（已上传数量） - 接收分片接口里，先读
.meta，更新received_chunks，若等于total_chunks则触发合并，并删除整个{upload_id}目录 - 对超过 2 小时未更新的
.meta，在合并失败或上传超时时主动清理——关键点是「清理动作必须和业务逻辑耦合」，而不是甩给后台任务
最易被忽略的是分片写入的原子性：不要先写分片再写 .meta，而应先写 .meta.tmp，成功后再 os.Rename 成 .meta，否则进程崩溃时元信息丢失，分片变成孤儿文件。
