Go http.ServeContent 怎么读取Range 区间

用 Go 的 http.ServeContent 处理文件或媒体片段时，不需要自己切字符串、计算偏移再写响应体。只要传入支持 Seek 的 io.ReadSeeker，它就会读取资源长度并解析客户端的 Range 请求；单个有效区间通常返回 206 Partial Content，并用 Content-Range 告诉客户端实际返回了哪些字节。

最小关键点是：Range: bytes=100-199 表示包含两端的字节区间，成功时检查 206 和 Content-Range: bytes 100-199/总长度；超出范围则看 416 与 Content-Range: bytes */总长度。

先让 ServeContent 拿到可 Seek 的内容

下面的示例用内存中的 bytes.Reader 说明调用关系。真实文件可以替换成 os.Open 返回的文件对象，接口不变。name 主要用于推断 MIME 类型，modtime 可参与 Last-Modified 条件请求。

package main

import (
    "bytes"
    "net/http"
    "time"
)

func assetHandler(w http.ResponseWriter, r *http.Request) {
    data := []byte("0123456789abcdefghijklmnopqrstuvwxyz")
    content := bytes.NewReader(data) // bytes.Reader 支持 Seek，适合演示分段读取
    http.ServeContent(w, r, "asset.txt", time.Unix(0, 0), content)
}

func main() {
    http.HandleFunc("/asset", assetHandler) // 只把资源路径交给 ServeContent
    _ = http.ListenAndServe(":8080", nil)   // 生产环境应处理并记录启动错误
}

这里不应把普通网络流直接当成 content。官方实现会先执行一次 Seek(0, io.SeekEnd) 获取大小，随后还要回到正确的读取位置；不能定位的流会在处理请求时失败。文件句柄则要由上层负责关闭，不能因为 ServeContent 接管了响应就忽略资源生命周期。

Range 的起止位置怎样换成响应片段

客户端发送单个区间时，语法是 bytes=起点-终点。例如资源长度为 36，bytes=10-15 取到的是第 10 到第 15 个字节，共 6 个字节；bytes=10- 则从第 10 个字节一直取到末尾。可以用 curl 观察响应头：

# 发送一个闭合区间；-i 用于同时查看状态和响应头
curl -i -H 'Range: bytes=10-15' http://127.0.0.1:8080/asset

# 只查看尾部区间，便于检查 bytes=start- 的语义
curl -i -H 'Range: bytes=-6' http://127.0.0.1:8080/asset

有效单区间的关键结果类似于：

HTTP/1.1 206 Partial Content
Content-Range: bytes 10-15/36
Content-Length: 6

Content-Range 的分母是完整资源长度，Content-Length 是这次响应体长度，两者含义不同。多个区间时实现会组织成 multipart/byteranges，如果调用方只需要断点续传，先围绕单区间处理通常更容易核对。

用状态码和响应头判断是否真的读对

例如对长度为 36 的资源请求 bytes=80-90，不能把空响应当作“读取成功但没有数据”。官方实现会给出 416，并把总长度放到 bytes */36 中，客户端可以据此重新计算区间。若是请求 bytes=-6，起点要由资源长度反推，不能把 6 当成起点。

缓存条件和 ReadSeeker 的两个生产检查点

如果资源会变化，传入可靠的修改时间，并按需要在写响应前设置格式正确的 ETag，ServeContent 还能参与 If-Modified-Since、If-Range 等条件请求。注意 If-Range 不匹配时，客户端期望的是完整响应，而不是继续拼接旧片段。

上线前至少检查两件事：第一，底层对象能否 Seek 到末尾再回到区间起点；第二，文件、对象存储或自定义 Reader 的关闭、并发访问和错误都由调用方管理。一个只实现 Read 的流应先落到可定位存储，或改用更适合流式传输的处理方式，别为了“支持 Range”在 handler 外层硬改 Content-Range。

相关问题

Range 的结束位置是否包含在响应中？

包含。bytes=10-15 的长度是 15-10+1，也就是 6；Content-Range 的首尾也会按这个闭区间表达。

为什么返回 416 而不是 206 和空正文？

因为请求区间与资源没有重叠，客户端需要知道资源当前长度。检查 Content-Range: bytes */size，再按新长度重试。

bytes.Reader 换成 os.File 需要改变 ServeContent 调用吗？

不需要，*os.File 同样实现 io.ReadSeeker；变化只在打开文件、处理错误和关闭句柄。