http.servecontent 不自动支持断点下载，需手动解析range头、校验合法性、设置accept-ranges和content-range头，并传入正确modtime；否则返回200而非206，且越界range须返回416。
Go 的 http.ServeContent 为什么没生效？
它不是“自动支持断点下载”的开关，而是需要你手动解析 Range 请求头、校验合法性、设置响应头后，再把它喂给 http.ServeContent —— 否则客户端收不到 206 Partial Content，只会当普通下载处理。
常见错误现象：curl -H "Range: bytes=100-199" http://localhost/file.zip 返回 200 OK 和完整文件，而不是 100 字节片段。
- 必须在
http.ResponseWriter上显式调用w.Header().Set("Accept-Ranges", "bytes") - 必须提前读取文件（或至少知道长度），用于校验
Range是否越界、计算Content-Range -
http.ServeContent第三个参数是modtime，传错会导致304 Not Modified错误触发，干扰分片逻辑
如何安全解析并校验 Range 头？
别直接信客户端传来的 Range 值，bytes=0-、bytes=-100、bytes=100-50 都是合法语法但需不同处理；超出文件大小的范围必须降级为 416 Range Not Satisfiable。
使用场景：静态文件服务、大资源 CDN 回源代理、内部构件分发服务。
立即学习“go语言免费学习笔记（深入）”；
- 用
http.ParseRange解析，它返回[][2]int64（支持多段，但 HTTP/1.1 实际只允许单段） - 检查切片长度：空切片 = 无 Range 或格式非法 → 当作全量请求（
200） - 对唯一区间
[start, end]，确保0 ；若 <code>end == -1，表示“从 start 到末尾” - 若
start >= filesize，必须返回416并写入Content-Range: */filesize
io.Seeker + io.SectionReader 是最稳的分片读法
直接 os.Open 后 file.Seek(start, 0) 再 io.Copy 看似简单，但并发下 Seek 和 Read 不是原子操作，可能读错位置；SectionReader 封装了偏移+长度约束，天然线程安全。
性能影响：相比全量读内存，SectionReader 零拷贝，仅增加一次 syscall seek，吞吐无损；兼容性上所有 Go 版本都支持。
- 构造：
sr := io.NewSectionReader(file, start, end-start+1) - 传给
http.ServeContent的content参数就是这个sr - 注意：
SectionReader.Size()返回的是“可读字节数”，要和Content-Length对齐
为什么 Content-Range 格式总出错？
它不是拼字符串就行：bytes 0-999/1000 和 bytes 0-999/* 语义完全不同；漏掉斜杠、数字错位、用错单位都会让 Chrome/Firefox 拒绝续传。
容易踩的坑：Content-Length 必须等于实际响应体字节数（即 end - start + 1），和 Content-Range 中的长度字段一致；两者不匹配，iOS Safari 会静默失败。
- 正确格式：
fmt.Sprintf("bytes %d-%d/%d", start, end, filesize) - 若请求是
bytes=500-且文件共 1000 字节 →start=500, end=999, filesize=1000 - 必须调用：
w.Header().Set("Content-Range", rngStr)和w.Header().Set("Content-Length", strconv.FormatInt(end-start+1, 10))
最麻烦的其实是边界：文件刚好 0 字节、Range 跨越 EOF、客户端用 1-based 坐标（它不会，HTTP 规范明确是 0-based）——这些地方一松懈，断点就变成重头下。
