gin框架本身不提供文件md5切片校验能力，必须手动集成crypto/md5与流式读取逻辑；切片校验本质是对整个文件做流式md5计算，而非对各分片单独哈希后拼接，因md5依赖完整字节序列与顺序，分片哈希拼接≠整体哈希。
直接说结论：Gin 框架本身不提供文件 MD5 切片校验能力，必须手动集成 crypto/md5 + 流式读取逻辑；切片校验不是“对每个分片算一次 MD5”，而是“对整个文件做流式 MD5 计算”，否则无法验证完整性。
为什么不能对每个分片单独算 MD5？
常见误区是给每个 chunk 单独计算 MD5 并存起来，以为拼起来就能还原文件指纹——这是错的。MD5 是全局哈希，依赖字节顺序和完整输入。分片 A 的 MD5 和分片 B 的 MD5 拼接 ≠ 整个文件的 MD5。
- 客户端上传前需先对原始文件做一次完整
md5.Sum，把结果（如fileMd5）作为元数据传给服务端 - 服务端接收所有分片后，在合并时用
io.MultiReader或逐个io.Copy到md5.Hash，再比对最终哈希值 - 若跳过合并阶段直接校验，必须用流式方式边读分片边写入哈希对象（不能先存文件再读——有 IO 开销且可能被篡改）
如何在 Gin 中安全流式计算大文件 MD5？
关键点是避免把整个文件加载进内存，尤其当文件 >1GB 时。Gin 的 c.FormFile 返回的是 *multipart.FileHeader，其 Open() 方法返回 io.ReadCloser，可直接喂给 md5.Hash。
- 不要用
fileHeader.Open().ReadAll()—— 这会把全部内容读进内存 - 正确做法：
file, err := fileHeader.Open() if err != nil { return err } defer file.Close() hash := md5.New() if _, err := io.Copy(hash, file); err != nil { return err } fileMd5 := fmt.Sprintf("%x", hash.Sum(nil)) - 注意：此方式仅适用于单文件上传场景；分片上传时，必须在合并阶段或合并前按序读取所有分片文件并流式写入同一
md5.Hash
分片上传中 MD5 校验该放在哪一步？
校验时机决定可靠性。生产环境推荐三处校验点，缺一不可：
-
上传前：客户端传
fileMd5字段，服务端仅存不验（防伪造） -
分片接收时：可选校验单个分片的
Content-MD5请求头（需前端配合计算），但无法保证整体完整性 -
合并完成时：用
os.Open打开临时分片目录下所有chunk_0001…chunk_N，按FileChunkNumber排序后，用io.MultiReader串连，喂给md5.New()—— 这才是唯一可信校验点
容易被忽略的坑：文件系统顺序与分片编号偏差
看似简单按数字排序分片文件，实际容易出错：
- Linux 下
ls chunk_*可能返回chunk_1,chunk_10,chunk_2（字典序），而非数值序 → 必须用sort.Slice+strconv.Atoi显式解析编号 - 分片编号从 0 还是 1 开始？前后端必须严格一致，建议统一用 0-based，避免合并时偏移
- 临时分片路径若含特殊字符（如空格、中文），
os.Open可能失败，应统一用 UUID 或纯 ASCII 命名，例如chunk_000001
真正难的不是写 MD5 计算逻辑，而是确保所有分片按原始顺序、无截断、无覆盖地参与哈希计算——中间任何一步跳过校验或乱序读取，MD5 就失去意义。
