对象存储分片上传：让大文件上传又稳又快

一个 2GB 的文件上传到 99% 时断了网，进度归零。单次 PUT 把成败押在一次请求上，文件越大，失败概率越高。对象存储的分片上传（Multipart Upload），正是为解决这个问题而生的。

一、什么是分片上传

分片上传把大对象切成多个 Part，每个 Part 独立上传，最后由服务端按编号合并。每个 Part 有编号（1～10000）和 ETag。好处有三：多片并发，速度成倍提升；单片失败只重传这一片；进度精确到分片，断点续传也有了落脚点。

二、核心流程只有四步

初始化：调用 InitiateMultipartUpload，拿到 UploadId。切片：按 5MB～100MB 切分，并行度 4～8 路。上传分片：每个 Part 带 PartNumber 和 UploadId 独立上传，记下返回的 ETag。合并：调用 CompleteMultipartUpload 提交清单，服务端校验后生成最终对象。失败或取消时，调用 AbortMultipartUpload 清理残留分片，否则碎片会一直占用存储并产生费用。

三、断点续传：把状态存下来

断点续传的本质是“上传前先把进度记下来”：把 UploadId、已上传分片的 ETag、文件指纹存到本地。续传时先调用 ListParts 查询服务端已收到的分片，只补传缺失的部分。文件指纹常用“大小 + 修改时间 + 采样哈希”，用来判断文件是否被改过——改过就不能再用旧的 UploadId。

四、秒传：先查后传

上传前先用文件哈希（SHA-256）查询服务端是否已有相同内容的对象，有则直接引用，跳过上传。秒传的本质是内容寻址，能省下大量带宽与时间。但它只适合可信租户内开启，且要做好租户隔离，避免用哈希“探测”他人文件。

五、容易踩的坑

分片太小：Part 上限一万片，片太小会让大文件超限；并发失控：并发过高会打满带宽、触发限流，建议控制在 4～8 路；忘记清理碎片：中断的上传会留下分片，最好用生命周期规则定期清理；中间分片必须大于等于 5MB，只有最后一片可以小于这个值；合并后对象的 ETag 不是文件 MD5，而是各分片 MD5 再做一次 MD5，不能直接拿它校验文件。

结语

分片上传把“一次定生死”变成了“分片可重试”，配合断点续传与秒传，大文件上传就从“祈祷不断线”变成了“断了也能接上”。超过 100MB 的文件，还在用单次 PUT 吗？