Revel中实现文件下载需手动控制响应流：禁用gzip、校验Range、设Accept-Ranges/Content-Range等头，用io.CopyN流式输出，显式处理HEAD方法。
Revel 中直接写文件下载接口，别碰 Content-Disposition 自动拼接
Revel 没有像 Spring Boot 那样内置 ResponseEntity<resource></resource> 或 StreamingResponseBody 的封装，它的 Controller.RenderFile() 会自动设置 Content-Disposition 和 Content-Type，但**不支持自定义 Range 处理逻辑**。一旦你调用 RenderFile("/path/to/file")，响应头就固定了，后续无法再改状态码或写 Content-Range。所以断点续传必须绕开它，手动控制响应流。
正确做法是：用 c.Response.Out 直接写入字节，并手动设置所有关键响应头：
-
Accept-Ranges: bytes—— 告诉客户端“我支持断点” -
Content-Type: application/octet-stream（或根据文件推断） - 若带
Range请求头，则返回206 Partial Content，并设置Content-Range和Content-Length - 若无
Range，则返回200 OK，按完整文件输出
手动处理 Range 请求头，用 http.ParseRange 解析更安全
Go 标准库的 http.ParseRange 能正确识别 bytes=0-、bytes=100-199、bytes=-500 等格式，并校验合法性（比如起始大于文件大小时返回错误）。别自己用 strings.Split 手撕。
实操要点：
- 先用
os.Stat()获取文件总大小，避免多次Seek或读取失败后才报错 - 调用
http.ParseRange(r.Header.Get("Range"), fileSize)，它返回[][]int64，单段请求通常只有一组 - 如果解析失败或范围越界，应返回
416 Requested Range Not Satisfiable，并带上Content-Range: */<filesize></filesize> - 用
io.CopyN或带io.LimitReader的io.Copy控制输出字节数，避免内存溢出
Revel 的 Response.Out 是 http.ResponseWriter，但要注意缓冲与超时
Revel 的 c.Response.Out 就是原始的 http.ResponseWriter，可直接用于 WriteHeader 和 Write。但有两个容易忽略的点：
- Revel 默认启用 gzip 中间件，若你手动写响应体，gzip 可能已提前 flush header，导致
WriteHeader失效 —— **务必在Before()阶段禁用 gzip（c.Response.DisableGzip = true）** - 大文件传输可能触发默认的 30 秒 HTTP 超时（Kestrel 或 Nginx 层），需同步调整反向代理和 Go
http.Server的ReadTimeout/WriteTimeout - 不要在循环中反复调用
c.Response.Out.Write()，改用bufio.NewWriter(c.Response.Out)包一层提升吞吐
断点续传真正难的不是代码，而是客户端行为一致性
浏览器对 Range 的使用并不统一：Chrome 下载器会发 Range 并接受 206，但 Safari 在某些版本里会忽略 Accept-Ranges，直接重发完整请求；wget/curl 默认支持，但 Electron 内嵌 WebView 可能因 User-Agent 被服务端误判。
所以生产环境必须：
- 在响应中始终返回
Accept-Ranges: bytes，哪怕当前没走Range分支 - 对非
Range请求也返回Content-Length，否则部分客户端无法计算进度 - 前端下载逻辑别依赖“服务端一定返回 206”，要用
response.status实际判断，再决定是否追加写入文件
最易被忽略的是：Revel 的路由匹配默认不区分 GET 和 HEAD，而断点续传常靠 HEAD 查询文件大小和是否支持 Range —— 记得在控制器里显式处理 HEAD 方法，只返回头不写体。
