Gin默认不支持断点续传，因其仅是轻量路由框架，不自动解析Range头或设置Accept-Ranges/Content-Range等必需响应头；直接调用c.File()会忽略Range请求并返回200 OK完整文件。
为什么 Gin 默认不支持断点续传？
Gin 本身是个轻量 HTTP 路由框架，gin.Context.Writer 底层用的是 http.ResponseWriter，它不自动解析或响应 Range 请求头，也不设置 Accept-Ranges、Content-Range 等断点续传必需的响应头。直接用 c.File() 或 c.Data() 返回文件时，客户端发起带 Range: bytes=1000- 的请求，Gin 会忽略该头，返回完整文件 + 200 OK，导致下载器无法续传。
如何手动实现 Range 请求处理？
核心是读取文件、解析 Range 头、计算偏移与长度、返回 206 Partial Content 并设置正确响应头。不要依赖 c.File()，改用 io.CopyN 或 io.Copy 配合 io.LimitReader 控制输出范围。
- 先用
os.Stat()获取文件大小，检查Range是否合法（如bytes=0-1023、bytes=1000-、bytes=-512） - 用
strings.Split()解析Range值，注意空格和单位（只支持bytes） - 调用
c.Writer.WriteHeader(http.StatusPartialContent)，并手动设置：Accept-Ranges: bytes、Content-Range: bytes 1000-4095/5000、Content-Length: 3096 - 打开文件后用
file.Seek(offset, io.SeekStart)定位，再用io.CopyN(c.Writer, file, length)写出指定字节数
常见错误：Range 解析失败或状态码不对
典型现象是浏览器或下载工具反复重试、卡在某个进度、甚至回退到从头下载。多数因为：
-
Range头没取到 —— 忘记用c.Request.Header.Get("Range")，而是用了c.GetHeader("Range")（后者是 Gin 封装，但行为一致；真正问题是没判空） - 返回了
200却设了Content-Range—— 这违反 HTTP 规范，客户端直接丢弃响应 - 文件打开失败后仍写了响应头 —— 导致 HTTP 头已发送但无 body，连接异常中断
- 未设置
Content-Type—— 某些客户端（如 curl -r）会因缺失类型拒绝解析 partial content
务必在写响应体前做完整校验：文件存在、可读、Range 合法、offset 不越界。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
性能与并发注意事项
每个断点请求都会打开一次文件，频繁小范围读取（如每 1KB 一个 Range）可能触发大量 open()/seek()/read() 系统调用。生产环境建议：
- 对大文件启用
os.O_RDONLY | os.O_DIRECT（Linux）绕过页缓存，但需对齐块大小，慎用 - 用
sync.Pool复用bufio.Reader实例，避免每次分配缓冲区 - 限制单个连接最大并发 Range 请求数，防止 fd 耗尽 —— Gin 本身不管理连接池，需靠反向代理（如 Nginx）或自定义中间件限流
- 避免在 handler 中直接
os.Open后长期 hold 文件句柄；defer file.Close()必须紧贴打开语句，否则 panic 时可能泄漏
断点续传逻辑看似简单，但 Range 边界计算、多段 Range（bytes=0-10,20-30）支持、ETag 校验这些边缘 case 很容易被忽略。除非业务强依赖，否则优先考虑用 Nginx 的 range 模块或对象存储的预签名 URL 直接卸载这部分逻辑。
