Go http.ServeContent 为什么 Range 请求会返回 416：Content-Range、Seek 与文件大小核对

播放器拖动到中间位置时，服务端日志突然出现一串 416，最容易误判成“浏览器的 Range 写错了”。用 Go 的 http.ServeContent 提供文件时，真正要先核对的是请求区间、io.ReadSeeker 当前偏移和文件总长度：三者只要有一个对不上，服务端就无法给出合法的 Content-Range。

先把 206 和 416 放回同一条请求链

一次范围请求至少涉及四个值：请求头里的 Range、文件总长度、服务端为读取准备的偏移，以及最终响应中的 Content-Range。例如文件长度是 1000 字节，客户端请求 bytes=100-199，合法响应应当是 206，范围是 bytes 100-199/1000。

如果客户端请求 bytes=1200-1300，起点已经越过文件末尾，416 才是合理结果。检查时别只盯状态码，响应头中的 Content-Range: bytes */1000 才是判断“服务器认为文件多大”的直接证据。

最小可用写法：让打开的文件从偏移零开始

os.File 同时满足读取和定位要求，适合直接交给 http.ServeContent。文件打开后不要为了探测 MIME 类型而留下一个已经前移的偏移；如果确实读过，调用前显式回到零点。

func serveVideo(w http.ResponseWriter, r *http.Request) {
    f, err := os.Open("media/demo.mp4")
    if err != nil {
        http.Error(w, "file unavailable", http.StatusNotFound)
        return
    }
    defer f.Close()

    if _, err := f.Seek(0, io.SeekStart); err != nil {
        http.Error(w, "seek failed", http.StatusInternalServerError)
        return
    }
    http.ServeContent(w, r, "demo.mp4", time.Time{}, f)
}

这里的文件名只用于响应头和内容类型推断，不是磁盘路径。磁盘权限、文件不存在和定位失败要在调用前处理；范围是否合法，则交给 ServeContent 根据可定位的内容判断。

收到 416 时按三步核对，不要先改客户端

第一步：记录原始 Range

保留完整的 Range 请求头，尤其注意是否混入多个区间。很多播放器只需要单段范围；代理或自写客户端把旧的偏移拼接两次，就可能形成越过末尾的请求。

log.Printf("range=%q if-range=%q", r.Header.Get("Range"), r.Header.Get("If-Range"))

第二步：比较文件长度和请求起点

用 Stat 或响应中的 Content-Range 对照文件实际长度。文件刚被替换、对象存储下载到一半、或者同一路径背后的内容发生变化，都会让播放器保存的旧范围失效。

第三步：确认 Seek 没被前置逻辑破坏

中间件如果先读取了文件，或者复用同一个文件句柄为多个请求服务，偏移就会互相影响。每个请求打开自己的句柄最简单；若必须复用，至少要保证并发定位和读取不会共享可变偏移。

几个看似能修复、实际会放大问题的变体

把所有 416 改成 200 会让部分播放器“看起来能播”，但它失去了断点读取能力，还可能让一次拖动下载整个文件。把 Range 直接裁剪到文件末尾也不稳：客户端可能期待的是一份旧文件，裁剪后的内容会与校验或播放器缓冲状态不一致。

更可靠的做法是：文件内容确实没有变化时保留标准范围语义；文件发生替换时通过版本化 URL、ETag 或合适的缓存策略让客户端重新建立范围。鉴权只负责决定能不能访问，不要在鉴权函数里消费文件流。

用 curl 验收响应头和边界

先测一个肯定落在文件内的区间，再测一个超出末尾的区间。下面的命令重点看状态、Content-Length 和 Content-Range，不要只看浏览器是否播放成功。

curl -i -H 'Range: bytes=0-99' http://127.0.0.1:8080/media/demo.mp4
curl -i -H 'Range: bytes=999999999-' http://127.0.0.1:8080/media/demo.mp4

如果第一条不是 206，先检查文件是否可定位以及服务端是否在调用前写入了响应体；如果第二条返回 416，且 Content-Range 给出了文件总长度，说明范围边界判断链路是完整的。

常见问题

为什么同一个文件第一次 206，第二次却 416？

常见原因是文件被替换或截断，客户端仍携带旧文件长度对应的范围。重新获取文件元数据并让客户端重新开始范围请求，通常比强行裁剪更可靠。

ServeContent 能处理多个 Range 吗？

它会按 HTTP Range 语义处理请求，但业务上仍应观察真实播放器和代理的行为。若链路只需要单段读取，优先记录并限制复杂输入，避免调试时把代理拼接问题误当成文件问题。

为什么不能用 bytes.Buffer 直接替代文件？

范围服务需要可靠的定位能力。普通 bytes.Buffer 不是按绝对偏移定位的 io.ReadSeeker；应使用文件、bytes.Reader 或自己实现并验证过的定位读取器。

收尾检查清单

• 日志记录了原始 Range、文件长度和响应状态。
• 每个请求使用独立句柄，或对共享句柄的偏移与并发有明确保护。
• 合法区间返回 206，越界区间返回 416，并带出准确的 Content-Range。
• 文件替换后有缓存失效或版本化 URL 的处理方式。