Golang实现大文件分块上传与断点续传系统设计-Golang-PHP中文网

直接用http.post传大文件会失败，因客户端将整个文件读入内存导致oom，服务端易超时或拒绝；网络中断后无法续传，必须采用客户端分片、服务端拼接与校验位记录方案。

golang实现大文件分块上传与断点续传系统设计

为什么直接用 `http.Post` 传大文件会失败

因为默认 HTTP 客户端没有分块能力，整个文件读进内存再发，1GB 文件直接 OOM；服务端也大概率在读取 body 时超时或拒绝。更关键的是，网络中断后只能重头来，没地方“续”。所以必须绕过一次性上传逻辑，改用「客户端切片 + 服务端拼接 + 校验位记录」三件套。

实操建议：

客户端用 os.Open 配合 io.CopyN 或 bufio.NewReader 分段读，每块控制在 5–20MB（太小增加 HTTP 开销，太大影响并发和内存）
每块请求带唯一标识：file_id（如 UUID）、chunk_index、total_chunks、chunk_hash（推荐 sha256.Sum256 前 16 字节）
服务端不要等全部块收完才写盘——收到一块就 os.WriteAt 到临时文件对应偏移，避免顺序依赖

`multipart/form-data` 不适合断点续传的真相

它本质是单次请求封装多字段，没法单独重传某一块，也不带块序号元数据。一旦中间某块失败，整个 multipart boundary 流就断了，服务端 parser 直接报 multipart: NextPart: bufio: buffer full 或 http: request body too large。

正确做法是每个块走独立的 POST /upload/chunk 请求，body 用纯二进制（Content-Type: application/octet-stream），靠 URL 参数或 JSON body 传元信息：

POST /upload/chunk?file_id=abc123&index=4&total=12
Content-Type: application/octet-stream

<binary data></binary>

服务端解析时注意：

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

校验 index ，防止恶意跳块攻击
用 io.ReadFull 确保读满预期字节数，否则说明客户端发送不完整
写入前先用 os.OpenFile(..., os.O_WRONLY|os.O_CREATE, 0644) 打开临时文件，再 file.WriteAt(data, int64(index)*chunkSize)

如何安全判断哪些块已上传（避免重复写/覆盖）

不能只靠客户端传来的 index 就信它——得服务端自己确认这块是否真实存在且完整。最轻量方案是维护一个内存 map + 持久化 fallback：

启动时扫描 /tmp/uploads/{file_id}/ 下所有 chunk_*.bin 文件，按文件名提取 index，存入 map[int]bool
每次接收新块前，先查这个 map；若已存在，直接返回 200 OK（幂等），不重复写
关键：写完块后立刻 file.Sync()，再更新 map，否则崩溃后状态不一致
生产环境建议把块状态存到 Redis（HSET upload:abc123 chunk_4 1），比文件系统快且可跨实例共享

漏掉 Sync() 是常见坑——Linux 默认页缓存延迟落盘，断电或 kill -9 后刚写的块可能消失，但 map 里却标记为已成功。