Revel框架不支持自动Range下载，需手动解析Range头、校验偏移、seek文件、设置206状态码及Content-Range等响应头，并独占文件句柄以避免并发错位。
Revel 框架本身不自动支持 Range 下载
Revel 的 Result 体系（如 RenderBinary、Stream）默认走完整响应流，不会解析 Range 请求头，也不会返回 206 Partial Content 或 Content-Range。它不拦截或重写 HTTP 状态码与头部，更不会帮你做文件 seek 和偏移写入——这些都得你手动补全。
必须手动处理 Range 头并返回 206 响应
不能依赖 c.RenderBinary() 或 c.Stream() 直接传文件；得自己读请求、校验、seek、分段写。关键步骤如下：
- 用
c.Request.Header.Get("Range")提取原始 Range 字符串，正则匹配出起始 offset（如bytes=1024-→1024） - 调
os.Stat()获取文件总大小，验证 offset 是否合法（offset ） - 用
os.OpenFile(filename, os.O_RDONLY, 0)打开文件，再f.Seek(offset, io.SeekStart)定位 - 设置响应头：
c.Response.Header().Set("Accept-Ranges", "bytes")、"Content-Range"（格式为bytes 1024-123456/123457）、"Content-Length"（剩余字节数） - 设状态码为
http.StatusPartialContent（206），再用io.CopyN(c.Response.Out, f, remainingSize)流式输出
并发下载时 Seek + Write 非原子，必须加锁或串行
多个客户端对同一文件发起不同 Range 请求时，Revel 默认每个请求是独立 goroutine，若共用一个 *os.File 句柄，Seek 和 Write 会相互干扰。常见错误现象是响应内容错位、重复或截断。
- 不要复用全局
*os.File；每次请求都os.Open()新句柄 - 若需复用句柄（如高频小文件），必须用
sync.RWMutex包裹Seek和Read操作 - 更稳妥做法：每个请求独占文件句柄，靠 OS 层面的 read-ahead 缓存提升性能，而非手动共享
Revel 的中间件和 Filter 不会自动透传 Range 逻辑
你写的 Range 处理代码必须放在具体 action 里，不能指望 Before filter 统一注入——因为 c.Response.Out 在 filter 阶段尚未绑定到底层连接，且 http.ResponseWriter 的 header 写入时机敏感。
- 别在
app.Init()或全局 filter 中尝试预设Accept-Ranges；它必须随实际响应动态计算 - 若要复用逻辑，封装成独立函数（如
serveRangeFile(c *revel.Controller, path string)），在各 action 中显式调用 - 注意 Revel 的
c.Params.Route和c.Params.Query不影响 Range 解析，Range是原始 request header，必须从c.Request读
Revel 没有隐藏的断点续传开关，所有 Range 行为都依赖你对底层 http.ResponseWriter 和 os.File 的精确控制——header、status、seek、copy，缺一不可。最容易被忽略的是：服务端返回 206 后，客户端是否真按 Content-Range 解析了字节范围，而不是当成 200 全量响应来追加写入。
