如何使用Golang实现文件下载断点续传_Golang网络文件传输-Golang-PHP中文网

Go中实现断点续传需手动用http.NewRequest设置Range头（如"bytes=1024-"），结合os.Stat获取已下载偏移量、os.OpenFile+Seek精确定位写入，服务端须返回206及Content-Range，否则应降级为全量下载。

如何使用golang实现文件下载断点续传_golang网络文件传输

如何用 `http.NewRequest` 发起带 Range 请求头的下载

断点续传本质是让服务端只返回文件的一部分，关键在客户端主动带上 Range 请求头。Go 标准库不自动处理这个，必须手动构造 *http.Request。

先用 os.Stat 检查本地已存在文件，获取当前长度作为 start；若文件不存在，start = 0
用 http.NewRequest("GET", url, nil) 创建请求，再调用 req.Header.Set("Range", "bytes="+strconv.FormatInt(start, 10)+"-")
注意：不要用 http.Get()，它无法设置自定义 header；也不要漏掉 req.Close = true，避免连接复用干扰续传逻辑
服务端必须支持 Accept-Ranges: bytes，否则会返回 200 而非 206，此时需提前校验响应状态码是否为 206 Partial Content

如何安全地追加写入已下载部分

直接 os.OpenFile(..., os.O_APPEND) 不行——它会在文件末尾追加，但 HTTP Range 返回的是从指定偏移开始的连续字节，必须精确写入对应位置。

用 os.OpenFile(path, os.O_WRONLY|os.O_CREATE, 0644) 打开文件，不加 O_APPEND
调用 file.Seek(start, 0) 移动到已下载末尾位置，再 io.Copy 写入响应体
务必检查 Seek 返回值，某些文件系统（如 FAT32）可能不支持大偏移量，会报 syscall.EINVAL
写入完成后建议调用 file.Sync()，防止断电或崩溃导致最后几 KB 丢失

如何判断下载完成并处理 200/206 状态混用

有些 CDN 或反向代理对 Range 请求返回 200 而非 206，且 Content-Length 是完整文件大小，容易误判“已下完”。不能只看状态码。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

优先检查响应头：resp.Header.Get("Content-Range") 是否非空，有则一定是 206；为空但 resp.StatusCode == 200，需进一步比对
计算本次应写入长度：expected := fileSize - start（若已知总大小），再对比 resp.ContentLength；若后者为 -1（流式传输），只能靠读取结束判断
更稳妥的方式：用 io.Copy 后检查实际写入字节数，若小于 expected 且 resp.ContentLength == -1，大概率是服务端不支持 Range，应放弃续传、重新从头下载

并发下载分块时如何避免文件错位和竞争

多 goroutine 分段下载本身能提速，但写文件时极易错乱——每个 goroutine 都要独立 seek 并写入，且不能依赖全局文件句柄共享。

每个分块 goroutine 必须打开自己的 *os.File（os.OpenFile），而非共用一个句柄；否则 Seek 相互覆盖
写入前先 file.Truncate(0) 清空临时文件（如 part_001.tmp），再 Seek(0, 0) 写入该段，合并时用 io.Copy 拼接
避免用 os.Rename 原地替换主文件——Windows 下会失败；应先写入临时名，再 os.Remove 原文件 + os.Rename
合并阶段无需加锁，但最终 os.Chmod 和 os.Chtimes 应放在所有分块写完之后统一执行

最常被忽略的是服务端对 Range 的实现差异：Nginx 默认支持，但 Caddy、某些 Go Web 框架需显式启用 http.ServeContent；没配好就会静默退化成全量响应，而客户端还在按断点逻辑处理，结果文件损坏。调试时先用 curl -v -H "Range: bytes=1000-2000" 手动验证服务端行为。