GoFiber 不原生支持断点续传，需手动实现 Range 请求解析、分块写入与校验；c.FormFile() 无法满足因它不处理 Content-Range、无偏移记录、无并发安全机制；MinIO 场景应优先使用其原生分块上传。
断点续传不是 Fiber 框架（GoFiber）原生支持的功能，它依赖你手动实现 HTTP 范围请求（Range / Content-Range）逻辑 + 存储层的分块校验与拼接。GoFiber 本身只提供路由、中间件和上下文控制能力，不封装文件上传协议细节。
为什么不能直接用 c.FormFile() 做断点续传
c.FormFile() 是一次性读取整个 multipart 表单文件，底层调用 ParseMultipartForm()，会把整个上传流缓冲进内存或临时磁盘 —— 这意味着无法感知客户端是否只传了部分字节，也无法响应 206 Partial Content 或校验已传分片。
- 它不解析
Range请求头，也不返回已存在文件的Content-Range响应 - 上传中断后，临时文件无元数据记录（如已接收 offset、total size、chunk hash），无法安全续传
- 并发上传同一文件时，缺乏原子性锁或分片去重机制，容易写坏
必须自己处理的三个核心 HTTP 协议点
断点续传本质是客户端和服务端对「文件偏移量」和「完整性」的协同约定，GoFiber 需显式支持以下行为：
- 上传前先发
HEAD或GET请求获取当前服务端已存大小 → 服务端需返回Content-Range: bytes */{total}或X-Upload-Offset: {offset} - 上传时客户端带
Content-Range: bytes {start}-{end}/{total}，服务端必须解析该 header 并 seek 写入对应位置 - 上传完成需校验所有分片 hash（如
ETag或自定义X-Chunk-Hash），不能仅靠文件长度判断完整
示例关键代码片段（非完整）：
app.Put("/upload/:filename", func(c *fiber.Ctx) error {
filename := c.Params("filename")
rangeHeader := c.Get("Content-Range") // e.g. "bytes 1000-1999/10000"
if rangeHeader == "" {
return c.Status(fiber.StatusPreconditionFailed).SendString("Missing Content-Range")
}
start, end, total := parseRange(rangeHeader) // 自行实现解析
file, _ := os.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0644)
file.Seek(int64(start), 0)
io.Copy(file, c.Body()) // 注意：此处需限制 body 大小为 (end-start+1)
return c.SendStatus(fiber.StatusPartialContent)
})
MinIO 场景下更推荐放弃“断点续传”而用分块上传（PutObject + ListParts）
如果你后端已集成 MinIO，不要自己实现基于文件系统的断点逻辑 —— MinIO 原生支持 S3 分块上传（CreateMultipartUpload / UploadPart / CompleteMultipartUpload），它自动处理：
- 每个 part 的独立 ETag（MD5 校验）
- part 列表持久化与查询（
ListParts可查哪些已传） - 超时未完成的 upload 自动清理（通过 lifecycle rule）
- 客户端可任意顺序上传 part，无需按 offset 对齐
GoFiber 中只需透传前端传来的 uploadId 和 partNumber，调用 minioClient.PutObject 即可，比手写 range 处理健壮得多。
真正容易被忽略的是：断点续传的可靠性不取决于框架，而在于 offset 记录的存储一致性。如果用本地文件存 offset，多实例部署时就会错乱；如果用 Redis 记 offset，又得处理网络分区下的写失败重试。这些都不是 Fiber 能帮你兜底的。
