Go 默认的 http.ServeContent 可自动处理 Range 请求与 Accept-Ranges 头，从而支持 MP4 等视频的客户端拖拽播放；而一次性读取整个文件到内存再发送则既不支持寻址，也存在内存和性能风险。
go 默认的 `http.servecontent` 可自动处理 `range` 请求与 `accept-ranges` 头，从而支持 mp4 等视频的客户端拖拽播放；而一次性读取整个文件到内存再发送则既不支持寻址，也存在内存和性能风险。
在 Web 视频播放中，“拖拽进度条”（即 seeking）依赖于 HTTP 协议的 字节范围请求（Byte Range Requests）：浏览器通过发送带 Range: bytes=xxx-yyy 头的 GET 请求，向服务器索要视频的某一段数据；服务器需响应 206 Partial Content 状态码，并返回对应字节范围及正确的 Content-Range、Accept-Ranges: bytes 等头部。若服务端未正确支持该机制，浏览器将无法显示进度条或拖拽失败——这正是原始代码的问题根源。
原始代码使用 ioutil.ReadFile 将整个 MP4 加载进内存，再通过 bytes.Buffer.WriteTo 全量输出，完全忽略 Range 头，且未设置 Accept-Ranges，因此不具备 seeking 能力。更严重的是，大视频（如数百 MB）会显著消耗内存并阻塞并发请求。
✅ 正确做法是利用 Go 标准库提供的 http.ServeContent ——它专为流式内容设计，自动解析 Range 请求、计算偏移、设置标准响应头、分块传输，并支持 If-Modified-Since 等缓存逻辑。示例如下：
package main
import (
"log"
"net/http"
"os"
"time"
)
func videoHandler(w http.ResponseWriter, r *http.Request) {
f, err := os.Open("./video.mp4")
if err != nil {
http.Error(w, "Video not found", http.StatusNotFound)
return
}
defer f.Close()
// ServeContent 自动处理 Range、Accept-Ranges、Last-Modified、ETag 等
// 第四个参数为 lastModified 时间（影响缓存），建议用文件实际修改时间
fileInfo, _ := f.Stat()
http.ServeContent(w, r, "video.mp4", fileInfo.ModTime(), f)
}
func main() {
http.HandleFunc("/video.mp4", videoHandler)
log.Println("Server starting on :8080...")
log.Fatal(http.ListenAndServe(":8080", nil))
}
? 关键说明：
- http.ServeContent 内部已完整实现 RFC 7233（HTTP Range Requests）规范；
- 它要求传入一个 io.ReadSeeker（*os.File 满足），以便随机定位读取；
- 响应头自动包含：Accept-Ranges: bytes、Content-Length（全量）或 Content-Range（分段）、Content-Type: video/mp4；
- 若请求含 Range，返回 206 Partial Content；否则返回 200 OK 并流式传输全部内容；
- 支持条件请求（如 If-Range），提升缓存效率。
⚠️ 注意事项：
- 不要使用 ioutil.ReadFile + bytes.Buffer 加载大文件——内存爆炸且无法 seek；
- 避免手动解析 Range 头并自行切片文件（易出错、难维护），除非有特殊分片/加密需求；
- 若需自定义路径映射或权限控制，可在调用 ServeContent 前做鉴权，但仍应委托其处理核心 range 逻辑；
- 对于超大视频或高并发场景，可结合 io.LimitReader 或异步缓冲优化 I/O，但基础 seeking 必须由 ServeContent 或等效机制保障。
总之，http.ServeContent 是 Go 中实现合规、高效、可 seek 视频服务的首选方案——简洁、健壮、符合标准，无需重复造轮子。
