分片上传需严格管理uploadId和partNumber：uploadId须初始化获取并妥善保存，partNumber必须从1开始连续递增；分片大小建议固定5MB以上；并发上传需用file.Seek定位+io.LimitReader避免指针混乱；断点续传依赖ListParts查询已传分片；CompleteMultipartUpload必须按partNumber升序提交服务端返回的ETag，否则报错。
分片上传必须自己管理 uploadId 和分片序号
Go 标准库没有内置的分片上传抽象，所有对象存储（如 AWS S3、阿里云 OSS、腾讯云 COS）都要求你先发起一个初始化请求，拿到唯一的 uploadId，后续每个分片都要带上它和明确的 partNumber。漏传、错传或重用 uploadId 会导致服务端拒绝合并或返回 InvalidPart 错误。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 把
uploadId存在本地临时文件或内存中，别硬编码；断点续传时靠它恢复上传上下文 -
partNumber必须从 1 开始连续递增，不能跳号、不能重复；哪怕某片上传失败重试，也要用原序号 - 分片大小建议固定（如 5MB），避免最后一片过小导致校验失败；S3 要求除最后一片外，其余分片 ≥ 5MB
并发上传分片时要注意 io.Seeker 和连接复用
直接对同一个 *os.File 并发调 io.Copy 会出错——文件指针被多 goroutine 扰乱，结果是部分分片内容错乱或为空。常见错误现象：合并后文件损坏、MD5 校验失败、EntityTooSmall 报错。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个分片上传前，用
file.Seek(offset, 0)定位到对应位置，再构造一个io.LimitReader(file, size)作为 body - 用
&http.Client{Transport: &http.Transport{MaxIdleConnsPerHost: 100}}提升并发能力，否则默认 2 个连接会严重拖慢速度 - 别在循环里反复
os.Open大文件，开一次就够了；关闭时机要等所有分片上传完再关
断点续传靠 ListParts 接口判断已传分片
重启程序后，不能假设“之前传了 3 片”，必须调用对象存储提供的 ListParts（S3）或 ListMultipartUploads（OSS）接口，查出哪些 partNumber 已成功提交。否则会重复上传、浪费带宽，甚至触发服务端限频。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每次开始上传前，先查一遍已存在的分片列表，构建
map[int]bool记录已传成功的序号 - 注意分片上传有超时（S3 默认 7 天），过期的
uploadId会被自动清理，查不到结果就得新建 - 某些 SDK（如
aws-sdk-go-v2）的ListParts返回分片无序，需手动按partNumber排序再比对
合并分片失败多数因为 ETag 不匹配或顺序错乱
调 CompleteMultipartUpload 时传入的分片信息必须包含完整的 partNumber 和服务端返回的 ETag（不是 MD5）。常见错误：把本地计算的 MD5 当成 ETag、漏传某个分片、partNumber 数组未按升序排列——这些都会导致 InvalidPart 或 InvalidPartOrder。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个分片上传成功后，立刻保存其
partNumber和响应头里的ETag（通常是双引号包裹的 hex 字符串，如"abc123..."） - 构造完成请求的
CompletedPart列表时，确保按partNumber升序排列；用sort.Slice显式排序，别依赖返回顺序 - 某些存储服务（如 MinIO）对 ETag 计算方式不同（非纯 MD5），不要试图本地校验，以服务端返回为准
最易被忽略的是：分片上传成功不等于数据落盘，CompleteMultipartUpload 才真正触发合并。这个 API 调用失败，前面所有分片就只是“待合并状态”，既不算成功也不算失败——得靠定时清理逻辑回收。
