Go环境无需特殊配置即可支持断点续传，只需手动构造带Range头的HTTP请求、校验206状态码、正确使用file.Seek或WriteAt写入，避免O_APPEND误用，并实测服务端是否真实支持Range。
Go 环境是否需要特殊配置才能支持断点续传
不需要。Go 标准库 net/http 本身完全支持手动构造 Range 请求，只要 Go 版本 ≥ 1.0（当前主流版本均满足），就具备全部底层能力。所谓“支持断点续传”，不是环境配置问题，而是你是否显式调用 http.NewRequest、设置 req.Header.Set("Range", ...)、校验 resp.StatusCode == http.StatusPartialContent，以及正确使用 file.Seek 写入。
为什么用 http.Get 无法实现断点续传
http.Get 是封装好的快捷函数，它不接受自定义 header，也无法控制请求方法细节。断点续传必须发送 Range 头，而 http.Get 永远不会加这个头 —— 即使你提前改了全局 http.DefaultClient 的 transport 或 roundtripper，也无效。
- 必须用
http.NewRequest("GET", url, nil)手动创建请求 - 再调
req.Header.Set("Range", "bytes="+strconv.FormatInt(offset, 10)+"-") - offset 必须来自
os.Stat(filename).Size()，不能硬编码或凭空猜测 - 结尾的短横
-不能漏，也不能写成bytes=1024-2047（除非你明确知道总长且服务端严格支持）
文件写入时最常踩的坑：O_APPEND 和 Seek 的误用
很多人以为打开文件加 os.O_APPEND 就能“接着写”，但这是错的：O_APPEND 强制所有 Write 落在文件末尾，完全忽略之前调用的 file.Seek。结果就是：你发了 Range: bytes=1024-，却把数据写到了文件开头或末尾，文件直接损坏。
- 正确打开方式是：
os.OpenFile(filename, os.O_WRONLY|os.O_CREATE, 0644)—— 不带O_APPEND，也不带O_TRUNC - 打开后立刻执行：
file.Seek(offset, io.SeekStart)，并检查返回值是否等于offset - 写入优先用
file.WriteAt(data, offset)，它不依赖当前文件指针，比Seek + Write更可靠 - 如果用
io.Copy，必须确保目标file已 Seek 到正确位置，否则它只管“从当前指针开始写”
服务端是否真支持 Range，不能靠猜
很多 CDN、Nginx 或反向代理会伪造 Accept-Ranges: bytes 响应头，但实际收到 Range 请求后仍返回 200 OK 全量内容。这种情况下，你以为在续传，其实是在重复写同一份数据，文件哈希必然失败。
立即学习“go语言免费学习笔记（深入）”；
- 上线前必须实测：
curl -I -H "Range: bytes=0-999" https://your-url/file.zip - 观察响应状态码是否为
206 Partial Content - 检查响应头是否有
Content-Range: bytes 0-999/123456，且长度匹配 - 不要只依赖一次 HEAD 请求的结果；每次下载前仍需对首次请求做状态码校验
最麻烦的从来不是代码怎么写，而是你根本不知道服务端在中间悄悄把 Range 头丢掉了，或者返回了伪造的 206。这类问题只能靠真实请求暴露，没法静态推断。
