是的，但需满足严格条件：必须显式传入准确的modtime、真实size和可seek的content函数，否则退化为完整响应；servefile因使用time.now()作modtime常导致拖拽失效。
Go 的 http.ServeContent 自动处理 Range 请求吗？
是的，但只在满足严格条件时才生效——它不是“开箱即用”的拖拽支持，而是个需要手动配合的半自动机制。很多人写了文件服务却拖不动进度条，问题就出在这里。
关键点在于：http.ServeContent 不会自己读文件、不解析请求头、也不设置响应头；它只在你提前提供正确 modtime、size 和一个能按需读取字节的 content 函数时，才检查 Range 头并切片返回。
- 必须显式传入文件最后修改时间（
modtime），否则它直接忽略Range，走完整响应流程 -
size必须是文件真实总大小（int64），不能是估算值或-1 -
content函数必须支持从任意偏移开始读（比如用io.Seeker），且不能缓存全部内容到内存
为什么用 http.ServeFile 拖拽经常失败？
http.ServeFile 看似简单，但它内部调用 http.ServeContent 时，传的是 time.Now() 作为 modtime —— 这导致 ETag 和 Last-Modified 不稳定，浏览器可能拒绝发送 Range 请求，或服务端因校验失败退化为 200 响应。
更隐蔽的问题：如果文件被并发修改（比如日志轮转），http.ServeFile 无法感知 size 变化，Range 请求可能返回错误长度甚至 panic。
立即学习“go语言免费学习笔记（深入）”；
- 开发时本地测试正常，上线后视频拖拽卡顿或重头加载 → 很可能是
modtime不一致触发了协商缓存失效 - 响应状态码是
200而非206→ 检查Content-Range头是否存在，不存在说明Range未被处理 - 用
curl -H "Range: bytes=100-199" http://x测试，返回 416 → 文件 size 传小了，或 offset 超出范围
手动实现 Range 解析时，http.ParseRange 怎么用才安全？
http.ParseRange 是标准库提供的解析工具，但它不校验范围合法性，也不处理多段 Range（bytes=0-100,200-300），实际视频场景几乎不用多段，所以通常只取第一个。
重点在后续校验：解析出的 start 和 length 必须手动与文件 size 对比，否则可能 panic 或返回越界数据。
ranges, err := http.ParseRange(r.Header.Get("Range"), fileSize)
if err != nil || len(ranges) == 0 {
// 不是合法 Range 请求，按普通 200 返回
http.ServeContent(w, r, name, modTime, file)
return
}
ra := ranges[0]
if ra.Start > fileSize || ra.Length == 0 {
http.Error(w, "Requested range not satisfiable", http.StatusRequestedRangeNotSatisfiable)
return
}-
http.ParseRange返回空 slice 表示无 Range 或语法错误，不要假设一定有结果 -
ra.Length是字节数，不是 end 偏移；ra.Start + ra.Length可能超过fileSize，需截断 - 浏览器发来的
Range: bytes=500-会被解析为Length = fileSize - 500，但依然要防Start > fileSize
视频文件响应必须设哪些 header 才让播放器识别拖拽？
除了 206 Partial Content 和 Content-Range，漏掉 Accept-Ranges: bytes 或 Content-Length 错误，会导致 Chrome / Safari 拒绝拖拽，静音播放器也可能卡住。
Content-Length 必须等于当前响应体字节数（即 ra.Length），不是原文件大小；而 Content-Range 格式必须严格为 bytes START-END/TOTAL，END 是闭区间（比如 bytes 0-999/1000）。
- 用
curl -I检查响应头：必须同时存在Accept-Ranges: bytes、Content-Range、Content-Length，且状态码是206 - 如果视频跨域播放，还需加
Access-Control-Allow-Headers: Range和Access-Control-Expose-Headers: Content-Range, X-Content-Range - 某些安卓 WebView 要求
Content-Type明确为video/mp4等，不能是application/octet-stream
事情说清了就结束。真正难的不是写对那几行 Range 逻辑，而是让每个环节的时间戳、长度、偏移、header 都严丝合缝——差一个字节，拖拽就断。
