Go微服务分片上传和断点续传失败主因是服务端默认行为与客户端用法冲突：r.ParseMultipartForm自动触发、os.O_APPEND强制追加、Nginx伪造Accept-Ranges，需首行禁用ParseMultipartForm并手动读r.Body。
Go 微服务里做分片上传和断点续传，90% 的失败不是因为逻辑写错，而是服务端默认行为和客户端惯性用法撞在一起——r.ParseMultipartForm 自动触发、os.O_APPEND 强制写末尾、Accept-Ranges 被 Nginx 伪造，三者叠加几乎必崩。必须从 handler 第一行开始就切断默认链路。
服务端必须禁用 r.ParseMultipartForm 并手动读 r.Body
标准库会在首次访问 r.MultipartForm 时隐式调用 r.ParseMultipartForm(32 ，把整个请求体塞进内存或临时文件，后续 <code>io.CopyN(r.Body, ...) 就读不到原始字节流。
- handler 开头第一行必须写
r.ParseMultipartForm(0)，0 表示禁用自动解析 - 元信息（
file_id、chunk_index、total_chunks）只能从r.URL.Query().Get("...")或r.FormValue("...")拿，别碰r.MultipartForm.Value - 二进制数据直接从
r.Body读，用io.CopyN(dst, r.Body, chunkSize)写入磁盘，路径建议为./uploads/{file_id}/chunk_{index:04d} - 写入前用
os.MkdirAll确保目录存在；并发写同一分片时，打开文件要加os.O_EXCL防覆盖
客户端续传前必须验证服务端真实支持 Range 请求
Accept-Ranges: bytes 响应头在 Nginx 或 CDN 上常被伪造，实际发 Range: bytes=0-1023 却返回 200 OK 或 500，导致续传逻辑误判。
- 首次下载前，先发试探请求：
HEAD /file.zip或GET /file.zip带Range: bytes=0-1023 - 仅当响应码为
206 Partial Content且Content-Range匹配（如bytes 0-1023/12345678）才启用续传 - 若返回
200，说明服务端不支持，应清空本地文件重下；若返回416，需用HEAD获取真实长度再重试 - 每次请求的
Range头必须严格为bytes={offset}-，不能多空格、不能结尾带横杠
写文件必须用 Seek 或 WriteAt，彻底弃用 os.O_APPEND
os.O_APPEND 是断点续传最大陷阱：它会让 Write() 忽略所有 Seek()，强制写到末尾，造成数据错位或空白填充。
立即学习“go语言免费学习笔记（深入）”；
- 正确打开方式：
os.OpenFile(filename, os.O_WRONLY|os.O_CREATE, 0644)（不加O_APPEND，也不加O_TRUNC） - 打开后立刻调用
f.Seek(offset, io.SeekStart)，并检查返回值是否等于offset；不等说明文件已被外部修改 - 更安全的写法是
f.WriteAt(data, offset)，它不依赖当前光标位置 - 写入前可选调用
f.Truncate(expectedSize)防止稀疏文件问题；并发写时Seek+Write非原子，需用sync.Mutex包裹或改单 goroutine 顺序写
分片状态必须持久化且跨实例共享
只存内存的 map[file_id]map[index]bool 在服务重启或滚动更新后就全丢，本地文件落盘又怕损坏，状态不一致会导致重复写或漏片。
- 生产环境强烈推荐用 Redis 存状态：
HSET upload:{file_id} chunk_{index} 1，SMEMBERS upload:{file_id}拉全量，毫秒级响应 - 启动时扫描
./uploads/{file_id}/下所有分片文件做 fallback，提取index初始化状态 - 每块写完立刻
f.Sync()，再更新状态；否则崩溃后磁盘有数据但状态没记，下次重传会覆盖 - 客户端重试前必须调用
/upload/status?file_id=xxx接口拉取已传列表，不能信本地缓存——设备可能换、浏览器可能清缓存
最易被忽略的是：服务端校验必须基于 Content-Range 头或客户端传来的 offset + size 三元组（file_id + offset + size），而不是单纯依赖 chunk_index。网络乱序、重试、恶意请求都可能让序号失真，只有偏移+长度才能准确定位字节区间。
