分片上传需自行管理offset、chunk ID等状态，避免内存溢出和空块错误；必须用multipart或raw bytes传输，禁用base64+JSON；并发需限流并校验每片etag；断点续传须以服务端parts列表为准。
分片上传必须自己管理 offset 和 chunk ID
Go 标准库没有内置「分片上传」抽象，http.Client 只管发请求，不记你传到第几块、哪块失败了、要不要重试。所有状态——当前偏移量、已上传 chunk_id、校验值、服务端返回的合并指令——都得你自己存、自己比对、自己续传。
常见错误是直接用 os.Open + io.Copy 一次性读整个文件再切片，内存爆掉；或者用固定大小 make([]byte, 1024*1024) 循环读，但没处理最后一块不足指定大小的情况，导致服务端收到空块或长度错乱。
- 每次读取前用
file.Seek(offset, io.SeekStart)定位，别依赖上一次读完的位置（并发上传时容易错乱） -
chunk_id建议用sha256(file_path + strconv.Itoa(chunkIndex))[:8]这类确定性生成方式，避免 UUID 导致服务端无法去重 - 最后一块读取后务必检查
n < len(buf)，显式截断buf[:n]再上传，否则可能带脏数据
HTTP 请求体必须用 multipart 或 raw bytes，别拼字符串
很多人想省事，把分片内容 base64 编码后塞进 JSON 字段里传，结果上传 100MB 文件时内存占用翻 1.3 倍、GC 压力陡增，还被服务端拒收——因为大多数对象存储或分片接口（如 TUS、七牛、阿里云 OSS 分片）只认 multipart/form-data 或纯二进制 Content-Type: application/octet-stream。
错误现象：400 Bad Request 且响应体含 "invalid part data" 或服务端日志显示 body length mismatch。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 用
mime/multipart.Writer构建表单：一个chunk_id字段 + 一个file字段（值为bytes.NewReader(chunkData)） - 若服务端接受 raw body，直接写入
req.Body = io.NopCloser(bytes.NewReader(chunkData))，并设req.Header.Set("Content-Type", "application/octet-stream") - 千万别用
fmt.Sprintf拼接 boundary 和二进制数据——换行符、编码、边界对齐全会出错
并发上传要控制 goroutine 数量，且必须等全部成功才触发合并
开 100 个 goroutine 同时上传 100 个分片？网络抖动时大量超时、重试、TCP 连接耗尽，反而比串行还慢。更危险的是：部分分片上传成功、部分失败，你却调了合并接口，服务端返回 404 Missing Part。
典型场景：用户选了一个 2GB 视频，前端切 5MB/片，共 400 片。你得确保这 400 次 HTTP 请求全部返回 200，且服务端确认每片 checksum 正确，才能发最终的 MERGE 请求。
- 用
semaphore.NewWeighted(3)（来自golang.org/x/sync/semaphore）限制并发数，3～5 是较稳的起点 - 每个分片上传后解析响应，提取服务端返回的
part_etag或upload_id，存进 map[string]string - 合并前遍历所有分片索引，确认每个
chunk_id都有对应 etag；缺一个就报错退出，不尝试“跳过”
断点续传靠服务端返回的 uploaded_parts 列表，不是本地文件名
你以为存个 uploaded_chunks.json 记录哪些 chunk_id 传过了就行？不行。服务端可能清理过期上传、合并策略变更、甚至同一文件多次上传产生不同 upload_id。本地记录只是辅助，真正权威的是服务端的 list-parts 接口返回结果。
容易踩的坑：上传中途 Ctrl+C，重启后直接从本地记录里找“没传的”，但服务端其实已经删掉了旧 upload session，导致后续合并失败。
- 启动续传前，先用初始
upload_id调一次GET /upload/{upload_id}/parts（或对应服务端接口） - 对比服务端返回的
uploaded_parts数组和本地待传列表，只补传服务端缺失的 chunk_id - 如果服务端返回
404 UploadNotFound，说明 session 过期，必须新建 upload_id，丢弃所有本地“已传”标记
最麻烦的永远不是怎么切片，而是怎么确认“这一块真的、稳稳地、被服务端认可地存进去了”。校验、重试、幂等、状态同步——这些没法偷懒，少一步，后面就卡在合并环节动不了。
