必须自己实现io.Reader分段读取，因为Go标准库无内置分片上传抽象，http.Client只认io.Reader且不会自动切块；直接传大文件会导致内存暴增、无法进度控制或断点续传。
分片上传为什么必须自己实现 io.Reader 分段读取？
Go 标准库没有内置“文件分片上传”抽象，http.Client 发起请求时只认 io.Reader，不会自动切块。如果你直接把整个大文件传给 http.NewRequest 的 body，内存会爆（比如 2GB 文件 → 至少 2GB 内存占用），而且无法做进度控制、断点续传或并发上传。
必须手动按块读取文件，每块封装成独立的 io.Reader（比如用 io.LimitReader + io.Seekable 配合 os.File），再逐块发请求。常见错误是用 os.ReadFile 全量加载，或用 bufio.Scanner 误以为能“分片”，其实它只是按行/字节缓冲，并不解决上传切片问题。
- 推荐方式：打开文件后用
file.Seek(offset, io.SeekStart)定位，再用io.LimitReader(file, chunkSize)构造当前分片 reader - 注意：文件需支持
io.Seeker（os.File支持，但bytes.Reader或网络流不支持） - chunkSize 建议设为 5–10MB；太小增加 HTTP 请求开销，太大影响并发和失败重试粒度
如何避免并发上传时 file.Seek 错位？
多个 goroutine 同时调用同一个 *os.File 的 Seek 和 Read，会相互覆盖偏移量 —— 这是 Go 文件句柄共享状态导致的典型竞态。现象是某些分片内容重复、错乱，甚至上传空数据。
根本解法不是加锁（锁住整个文件读太慢），而是为每个分片创建独立的文件句柄：
立即学习“go语言免费学习笔记（深入）”；
- 用
os.Open在每个 goroutine 中重新打开文件（操作系统级 fd 复制，开销可控） - 然后立即
file.Seek(offset, io.SeekStart)，再读取对应 chunk - 别复用
*os.File实例；也不要依赖单个 file 的 seek + read 组合在并发中安全 - 记得每个 goroutine 里
defer file.Close()，避免 fd 泄露
multipart/form-data 分片上传时字段名和边界怎么配？
后端接收方（比如用 req.MultipartReader() 解析）对字段名、文件名、Content-Disposition 格式非常敏感。常见错误是前端拼出的 multipart body 被后端解析失败，报 multipart: NextPart: unexpected EOF 或字段丢失。
关键点在于：每个分片必须作为独立的 multipart/form-data 请求发送（不是把所有分片塞进一个请求），且每个请求中：
- 文件字段名统一（如都叫
file），但需额外带分片元信息字段，例如chunk_index、total_chunks、filename -
Content-Dispositionheader 必须含name="file"和filename="xxx"（即使分片，filename 应保持原始名） - 不要手动生成 boundary —— 用
mime/multipart.Writer自动生成并写入 header，否则容易格式错位 - 示例片段：
writer, _ := multipart.NewWriter(&buf) _ = writer.WriteField("chunk_index", strconv.Itoa(i)) _ = writer.WriteField("total_chunks", strconv.Itoa(total)) part, _ := writer.CreateFormFile("file", originalName) io.Copy(part, chunkReader)
断点续传靠什么判断哪些分片已成功？
服务端必须返回每个分片的唯一标识（比如 chunk_id 或 md5(chunk_data)），客户端不能只靠序号。因为网络重试可能导致同一分片被上传多次，而服务端去重逻辑依赖的是内容哈希或服务端生成的 token，不是客户端传的 chunk_index。
实际做法是：上传完一个分片后，解析响应 JSON，提取服务端返回的该分片确认凭证（如 {"status":"ok","chunk_hash":"a1b2..."}），本地记录到一个临时映射表（比如 map[int]string 或写入磁盘的小型 JSON 文件）。下次启动时先比对，跳过已确认的分片。
- 千万别只靠
HTTP 200就认为成功 —— 可能服务端写入失败但返回了 200 - 如果服务端不返回校验值，客户端至少应计算并上传
md5或sha256，让服务端核对 - 临时记录文件路径建议用
filepath.Join(os.TempDir(), "upload_"+md5(filename)[:8]+".json")，避免冲突
Seek 错一位、boundary 少两个换行、chunk_hash 算法和服务端不一致，都会导致整份文件无法拼合。 
