http.servecontent是唯一靠谱选择，因支持range请求、自动生成etag/last-modified、复用文件句柄；必须用os.open+filepath.clean+前缀白名单校验路径，禁用set-cookie，显式设cache-control，确保cdn缓存命中。
Go 本身不提供“文件分发系统”这个现成模块，所谓高效，本质是组合 HTTP 服务能力、路径安全控制、响应头策略和 CDN 协作逻辑。直接用 http.ServeFile 或裸 io.Copy 基本等于放弃缓存、暴露路径、无法断点续传。
为什么 http.ServeContent 是唯一靠谱的选择
它支持 Range 请求（视频拖拽、大文件断点续传）、自动生成 ETag 和 Last-Modified（CDN 缓存命中的前提）、能复用文件句柄（避免内存拷贝）。而 http.ServeFile 不校验路径、不设缓存头、不支持协商缓存，io.Copy + os.ReadFile 更是彻底禁用 Range —— 因为没提供 io.ReaderAt 接口。
- 必须用
os.Open打开文件，不能用os.ReadFile或内存 buffer -
filepath.Clean必须配合前缀白名单做二次校验，单靠Clean不防绕过（比如/data/../etc/passwd） -
http.ServeContent第四个参数必须是fi.ModTime()，否则Last-Modified为空，CDN 拒绝缓存
CDN 缓存失效的三个硬性条件
CDN 只看响应头，不看你代码多优雅。缺任意一个，它就强制回源。
- 必须显式设置
Cache-Control: public, max-age=31536000（静态资源建议 1 年） - 必须让
http.ServeContent生成ETag和Last-Modified—— 这依赖真实文件的os.File.Stat()，加密流或 bytes.Buffer 不行 - 绝对禁止返回
Set-Cookie头，哪怕只在开发环境加了调试 cookie，CDN 会直接跳过缓存
验证方法：curl -I https://your.cdn.domain/file.pdf，检查是否同时含 Cache-Control、ETag、Last-Modified，且无 Set-Cookie。
大文件拖拽失败或播放卡顿的根因
不是带宽问题，而是服务端没正确响应 Range 请求。浏览器/播放器发来 GET /video.mp4 HTTP/1.1\r\nRange: bytes=1024-2047\r\n，你却返回 200 + 全量内容，它就只能重载整个文件。
- 确保 handler 中没有提前调用
io.Copy、json.NewEncoder.Encode或任何写响应体的操作 - 不要在
http.ServeContent前设置Content-Length—— 它会自动根据Range计算 - 如果用了中间件（如日志、鉴权），必须确认它们不消费请求 body，否则
Range信息丢失
静态资源路径校验的最小安全模式
别信“我只绑定了 /files 路由”这种想法。攻击者能拼出 /files/../../../etc/shadow，filepath.Clean 后变成 /etc/shadow，再不加白名单就完了。
- 拼接路径用
filepath.Join(staticRoot, filepath.Clean(path))，不是字符串拼接 - 校验必须是
strings.HasPrefix(cleanPath, staticRoot)，且staticRoot末尾带斜杠（如/data/assets/） - 拒绝所有非白名单后缀：对
.env、.yaml、.log等敏感扩展名直接http.Error(w, "", http.StatusForbidden)
真正卡住上线的，往往不是 Go 语法，而是漏掉其中一环：比如忘了删调试用的 Set-Cookie，或者用 os.ReadFile 代替 os.Open 导致视频无法拖动——这些细节不跑真实大文件+ CDN 实测，根本发现不了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
