go语言无内置分片上传框架，需手动实现状态管理、io.readat按偏移安全读取（检查n并截断）、禁用base64+json（改用multipart或raw bytes）、并发限流（3–5 goroutine）、服务端校验etag、断点续传依赖/upload/status接口查询已传分片。
Go 语言没有内置分片上传框架，所有状态管理、偏移控制、并发协调、断点续传逻辑都得你自己写。标准库 http.Client 和 net/http 只提供 HTTP 通信能力，不维护上传进度、不缓存已传分片、不自动重试失败块——这些必须由你显式实现。
怎么用 io.ReadAt 安全读取指定分片
错误做法是 os.ReadFile 或循环 file.Read 累积偏移，容易错位或内存溢出。正确方式是打开文件后，用线程安全的 ReadAt 按绝对偏移读固定长度：
- 先
file.Stat()拿到Size()，算出总片数：totalParts := int((size + chunkSize - 1) / chunkSize) - 每片调
n, err := file.ReadAt(buf[:], int64(partIndex)*int64(chunkSize))，不是依赖上一次读完的位置 - 必须检查
n ，最后一片要截断：<code>data := buf[:n]，否则可能带前一片残留数据 - 别用
bufio.Reader包裹文件再调ReadAt——它内部维护缓冲区，会破坏随机读语义
为什么不能用 base64 + JSON 传分片
常见错误是把二进制分片 base64.StdEncoding.EncodeToString(chunkData) 塞进 JSON 字段上传。这会导致：
- 内存占用暴涨约 1.3 倍（base64 编码膨胀 + JSON 字符串堆分配）
- GC 压力陡增，尤其在高并发上传时触发 STW
- 服务端拒绝接收：对象存储（MinIO/OSS/TUS）只认
multipart/form-data或application/octet-stream，收到 JSON 就返回400 Bad Request并带"invalid part data" - 若坚持用 raw body，必须设
req.Header.Set("Content-Type", "application/octet-stream")，且req.Body = io.NopCloser(bytes.NewReader(data))
并发上传必须限流且等全部成功才合并
开 20 个 goroutine 同时上传 20 个分片？网络抖动时大量超时、TCP 连接耗尽、重试雪崩，反而比串行慢。更危险的是部分成功就调合并接口，服务端返回 404 Missing Part。
- 用
semaphore或带缓冲 channel 控制并发数（建议 3–5） - 每个分片上传后必须校验服务端返回的
ETag（如 MinIO 的 MD5）是否匹配本地计算值 - 用
sync.WaitGroup等所有 goroutine 返回，任一失败就中断，不触发合并 - 失败分片需记录
uploadID + partNumber到本地磁盘（如 SQLite 或 JSON 文件），下次启动先查再跳过已成功项
断点续传靠服务端状态，不靠客户端缓存
客户端本地存“上次传到第几块”不可靠——浏览器清缓存、设备切换、进程被杀都会丢状态。真正可用的断点续传，必须依赖服务端可查询的已传分片列表。
- 服务端提供轻量接口，如
GET /upload/status?upload_id=abc123，返回{"uploaded_chunks": [0,1,4], "total_chunks": 10} - 该接口响应必须毫秒级，推荐用 Redis 的
SET类型存upload_id:chunks，SMEMBERS拉全量 - 客户端每次上传前必先调此接口，只重传缺失索引，避免重复上传浪费带宽
- 如果服务端返回的
total_chunks和客户端初始值不一致，说明服务端状态异常，应放弃当前 upload_id，重新初始化会话
最易被忽略的点是服务端对请求体大小的防护：Go 默认不限制 Request.Body 长度，恶意上传可直接 OOM。必须在路由前用 http.MaxBytesReader 包裹，并配 r.ParseMultipartForm(32 控制内存缓冲上限——否则单个 2GB 分片就能拖垮整个服务。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
