分片上传需禁用Echo默认解析，直接读取c.Request().Body并用multipart.NewReader()手动解析，且必须调用r.ParseMultipartForm(32<<20)设置MaxMemory防OOM。
分片上传时如何正确解析 multipart/form-data 请求体
Echo 默认的 c.FormValue() 和 c.MultipartForm() 在大文件场景下容易阻塞或 OOM，因为它们会把整个请求体读入内存。分片上传必须绕过默认解析，直接读取原始 io.ReadCloser。
关键点是禁用 Echo 的自动解析：在路由注册前调用 e.DisableHTTP2 = true（非必需但可减少 HTTP/2 流控干扰），更重要的是在 handler 中跳过 c.MultipartForm()，改用 c.Request().Body 配合 multipart.NewReader() 手动解析：
func uploadHandler(c echo.Context) error {
r := c.Request()
// 必须设置 MaxMemory，否则 multipart 仍可能全量加载
if err := r.ParseMultipartForm(32 << 20); err != nil && err != http.ErrNotMultipart {
return err
}
mr, err := multipart.NewReader(r.Body, r.MultipartForm().Get("boundary"))
if err != nil {
return err
}
// 后续逐个读取 part，不调用 FormValue 或 MultipartForm.Value
}
ParseMultipartForm(32 是必须的，它只解析头部、设置 boundary，不加载文件体；省略它会导致 <code>multipart.NewReader无法识别分界符- 不要调用
c.MultipartForm().Value或c.FormValue()，它们会触发完整解析并缓存所有 part - 每个
part的Header.Get("Content-Disposition")需手动解析 filename、chunkIndex 等字段，Echo 不提供现成工具
如何安全存储和校验上传的分片文件
分片不能直接写入最终路径，必须先落盘到临时目录，并带唯一标识（如 upload_id/chunk_0001.bin），否则并发上传同一文件时会发生覆盖或错乱。
推荐结构：/tmp/uploads/{upload_id}/{chunk_index}.{ext}，其中 upload_id 来自前端传入的字段（如 UUID），chunk_index 从 Content-Disposition 或额外表单字段中提取。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 使用
os.CreateTemp("/tmp/uploads", "chunk-*.bin")创建临时文件更安全，避免路径遍历；再 rename 到目标位置 - 每片写入后立即计算 SHA256（或 MD5）并存入内存 map 或 Redis，用于后续合并前校验完整性
- 务必设置超时清理：上传 ID 对应的所有分片若 24 小时未完成合并，应由后台任务自动删除
- 不要依赖文件名后缀判断类型——分片无扩展名，应通过
part.Header.Get("Content-Type")或首字节 magic number 校验
合并分片时如何避免阻塞主线程和磁盘爆满
合并操作耗时且占 I/O，绝不能在 HTTP handler 中同步执行。Echo 的 handler 必须快速返回响应，合并应交由 goroutine 异步处理，并通过 Redis 或数据库记录状态供前端轮询。
典型流程：收到最后一片 → 写入完成标记 → 启动异步合并 → 返回 {"status":"merging","upload_id":"xxx"}。
- 合并前先按
chunk_index排序并确认数量匹配总片数（来自total_chunks表单字段） - 用
os.OpenFile(..., os.O_CREATE|os.O_WRONLY|os.O_APPEND)追加写入目标文件，避免一次性读入所有分片到内存 - 每写入一片后调用
runtime.GC()并检查磁盘剩余空间（syscall.Statfs），低于阈值（如 5GB）立即中止并报错 - 合并失败时保留分片目录，记录错误日志，方便人工介入；不要自动删光所有分片
前端传参与后端校验的常见断层点
前端 JS 用 FormData.append("chunk", blob, "name") 时，blob 没有真实文件名，后端拿到的 filename=""。必须显式传额外字段，否则无法关联分片。
- 必须传递三个关键字段：
upload_id（UUID）、chunk_index（从 0 开始）、total_chunks（总数），全部作为普通 form 字段，而非文件字段 - 后端必须校验：
chunk_index >= 0 && chunk_index ，防止恶意跳片或重复提交同一片 - 对
upload_id做长度和格式校验（如正则^[a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89ab][a-f0-9]{3}-[a-f0-9]{12}$），避免路径注入 - 不要信任
Content-Length头——分片上传中该值常为单片大小，不是总大小；总大小应由前端在首片中通过额外字段声明
最易被忽略的是并发控制：多个请求可能同时写入同一 upload_id 下的分片目录。要么用 Redis 分布式锁（SET upload_id:lock "1" NX EX 30），要么在写入分片前先 os.Stat 检查文件是否存在并跳过——后者更轻量，但需接受极小概率的重复写入（不影响最终合并结果）。
