c.File()不支持断点续传因其调用http.ServeFile且未处理Range头、未设Accept-Ranges和206状态码；手动实现需解析Range、设置响应头、流式读取文件片段。
为什么 c.File() 无法支持断点续传
因为 c.File() 内部调用的是 http.ServeFile，它直接读取整个文件并写入响应体，不检查请求头中的 Range，也不设置 Accept-Ranges: bytes 和分段响应状态码（如 206 Partial Content）。浏览器发起断点请求时，服务端仍返回 200 OK 和完整文件，客户端只能重下，无法续传。
手动实现流式断点下载的关键三步
核心是绕过框架封装，接管 http.ResponseWriter 并按需读取文件片段。必须自己解析 Range 头、计算偏移与长度、设置正确响应头：
- 先用
stat, err := os.Stat(filePath)获取文件大小，校验是否存在且可读 - 解析
c.Request.Header.Get("Range")，匹配bytes=xxx-yyy格式；若不存在，按全量下载处理（200+Content-Length） - 若存在
Range，计算start和end（注意end不能超过文件大小），设置c.Status(206)、c.Header("Content-Range", "bytes "+strconv.FormatInt(start,10)+"-"+strconv.FormatInt(end,10)+"/"+strconv.FormatInt(stat.Size(),10))、c.Header("Accept-Ranges", "bytes") - 用
file.Seek(start, io.SeekStart)定位，再用io.CopyN(c.Writer, file, int64(end-start+1))流式输出，避免内存加载整块
io.CopyN 与 io.LimitReader 的选择差异
两者都能控制读取字节数，但行为不同：
-
io.CopyN(dst, src, n)：严格复制恰好n字节，若src提前 EOF，则返回io.ErrUnexpectedEOF—— 这在断点下载中需捕获并转为错误处理 -
io.LimitReader(src, n)：包装src，后续所有读操作累计不超过n字节，超出部分返回0, io.EOF—— 更适合流式场景，无需额外判断长度 - 实践中推荐用
io.LimitReader(file, end-start+1)配合io.Copy(c.Writer, limitedReader)，逻辑更清晰，也兼容net/http的底层缓冲机制
并发读取大文件时的文件句柄泄漏风险
每次调用 os.Open() 都会分配一个文件描述符，若未显式 Close()，高并发下很快触发 too many open files 错误。尤其在断点下载中，同一文件可能被多个请求同时打开：
- 务必在
defer file.Close()前确认file非 nil，否则 panic - 不要复用全局
*os.File变量——文件指针位置不可控，多 goroutine 读会相互干扰 - 考虑用
sync.Pool缓存*os.File实例？不推荐。文件对象本身不轻量，且Close()后不可复用；更稳妥的是确保每个 handler 生命周期内只开一次、关一次 - 生产环境建议加
syscall.Getrlimit(syscall.RLIMIT_NOFILE, &limit)监控当前限制，并在日志中记录open失败的具体路径和错误
Content-Length 或 Transfer-Encoding: chunked 的准确响应。如果用 io.Copy 直接写入未设置 Content-Length 的 c.Writer，且文件大小恰好被 TCP 分片截断，某些旧版客户端（如部分 Android WebView）会认为传输中断而失败。务必在 206 响应中显式设置 Content-Length: end-start+1。 
