r.parsemultipartform(0)是服务端第一行必须写的代码，因其显式禁用内存缓存，强制所有文件内容直接落盘，避免oom；否则默认32mb内存阈值仍可能导致大文件内存暴涨或解析失败。
直接用 os.ReadFile 或 http.Post 传大文件，90% 的失败不是网络问题，而是 IO 模式错配：内存爆掉、指针错乱、服务端流被提前消费、写入位置漂移——这些都不是“功能没做全”，是底层 IO 原语用错了。
为什么 r.ParseMultipartForm(0) 是服务端第一行必须写的代码
Go HTTP 标准库会在你第一次访问 r.MultipartForm 或隐式调用 r.ParseMultipartForm 时，自动执行 r.ParseMultipartForm(32 。这意味着：整个请求体（哪怕 2GB）会被读进内存或临时文件，<code>r.Body 随即变为空。后续你再想用 io.CopyN(r.Body, ...) 读分片？读到的是 EOF。
正确做法只有一条：在 handler 开头第一行就写 r.ParseMultipartForm(0)。传 0 表示禁用自动解析，强制保留原始字节流。
- 元信息（如
upload_id、chunk_index）必须从r.URL.Query().Get("chunk_index")或r.Header.Get("X-Upload-ID")获取，别碰r.MultipartForm.Value - 如果非要带额外字段（比如 JSON 描述），改用
r.MultipartReader()手动流式解析，避免全量加载 - 不加这行，所有分片上传都会静默失败——最后一片写入空数据，合并后文件开头正常、中间大片空白、结尾错位
客户端用 file.Seek + io.LimitReader，而不是反复 os.Open
每个分片都 os.Open 一次大文件？系统 fd 很快耗尽；用 file.ReadAt(buf, offset) 却忽略返回的 n, err？最后一片可能读不满但发了完整 Content-Length，服务端校验直接拒绝。
正确姿势是：打开一次文件句柄，上传全程复用它。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先
file.Seek(offset, io.SeekStart)定位，检查返回值是否等于offset（防止文件被截断） - 再用
io.LimitReader(file, partSize)包装，作为 HTTP 请求 body -
partSize必须是整数，别用float64计算后转int，浮点误差会导致最后一片偏移错位 - 读取后立刻算
sha256.Sum256(partData)，和服务端回传的X-Part-SHA256对，别等全部传完再校验
os.O_APPEND 是写入阶段最危险的 flag
看起来“追加”很安全，实际它是断点续传最大陷阱：只要开了 os.O_APPEND，所有 Write() 都会忽略之前 Seek() 的定位，强制写到文件末尾。结果就是：本该写在 offset=10MB 的数据，被写到了 2GB 文件末尾，中间全是 \x00 填充，文件静默损坏。
正确打开方式是：os.OpenFile(path, os.O_WRONLY|os.O_CREATE, 0644)，不加 O_APPEND，也不加 O_TRUNC。
- 写入必须用
file.WriteAt(data, offset)，它不依赖当前光标，比Seek + Write更可靠 - 并发写同一分片时，用
os.OpenFile(..., os.O_EXCL)靠系统级原子性防覆盖 - 每次写完立刻
file.Sync()，否则崩溃后状态不一致
Range 请求不是设个 header 就能续传
只看响应头有 Accept-Ranges: bytes 毫无意义——Nginx、CDN 常伪造这个 header，但实际对 Range: bytes=1024- 返回 200 OK 或直接 500。必须发试探请求验证真实行为。
- 下载前先发一个
HEAD /file.zip或带Range: bytes=0-1023的 GET 请求 - 仅当响应码为
206 Partial Content且Content-Range头匹配（如bytes 0-1023/12345678）才启用续传逻辑 - 遇到
416 Range Not Satisfiable，先发HEAD拿最新Content-Length，对比本地文件大小：不一致就得全量重下 -
Range头格式必须严格为bytes={offset}-，结尾短横不能少，也不能多空格
真正卡住人的从来不是“怎么实现断点续传”，而是 io.Seeker 在并发下的指针竞争、r.Body 被标准库悄悄吃掉、os.O_APPEND 暗中破坏偏移——这些细节不抠清楚，写一万行代码也救不回一个损坏的视频文件。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
