go range下载需手动设range头并校验206状态码，并发写用共享file.writeat，限流用io.limitreader，续传依赖主文件大小而非临时分片，最终以完整文件哈希校验。
Go 用 http.NewRequest 发起 Range 请求，别漏掉 Range 头和状态码校验
Range 下载的前提是服务端支持分片，而 Go 默认的 http.Get 不带 Range 头，必须手动生成请求。常见错误是只加了头但没检查响应状态码——服务端不支持时返回 200（全量）而非 206（部分），导致后续合并逻辑错乱。
- 用
http.NewRequest("GET", url, nil)创建请求，再调用req.Header.Set("Range", "bytes=0-1023") - 务必检查
resp.StatusCode == http.StatusPartialContent，否则说明 Range 被忽略，得降级为单连接下载或报错退出 - 某些 CDN 或 Nginx 配置下，
Accept-Ranges: bytes响应头存在 ≠ 实际支持 Range；最终以状态码为准 - 不要复用同一个
*http.Client实例发多个 Range 请求却不设Timeout——某个分片卡住会拖垮整个下载器
并发写文件要用 os.OpenFile + file.WriteAt，别用 os.Create 或 file.Write
多个 goroutine 同时写一个文件，如果各自打开再写，轻则覆盖，重则 panic（“bad file descriptor”）。file.Write 是顺序写，无法指定偏移；而 file.WriteAt 才能精准落盘到指定字节位置。
- 主文件必须用
os.OpenFile(path, os.O_CREATE|os.O_RDWR, 0644)一次性打开，所有 goroutine 共享这个*os.File - 每个分片 goroutine 拿到自己的
start偏移后，直接调file.WriteAt(data, int64(start)) - 注意：Windows 下
WriteAt可能不原子，但对下载合并影响不大；Linux/macOS 完全可靠 - 别在 goroutine 里 defer
file.Close()——主协程要等所有分片写完才关，否则文件句柄提前释放
io.Copy 配合 io.LimitReader 控制分片大小，避免内存爆掉
用 io.Copy 直接把 HTTP body 写进 buffer 容易 OOM，尤其当服务端不守约、返回远超 Range 指定长度的数据时。必须限流，且不能依赖 Content-Length——它可能缺失或不准。
- 对每个分片响应体，包一层
io.LimitReader(resp.Body, int64(chunkSize))，chunkSize就是该分片理论长度 - 然后用
io.Copy写入bytes.Buffer或直接WriteAt到文件——后者更省内存 - 读完后检查实际写入字节数是否等于
chunkSize，不等就说明服务端提前 EOF 或出错，需重试或报错 - 别用
resp.Body.Read()自己循环读——容易丢字节或阻塞，io.Copy内部已做最优缓冲
合并完成前别删临时分片，断点续传靠的是 os.Stat 检查已写范围
下载中途失败，下次启动不是从头开始，而是扫描目标文件已存在的字节范围，跳过已成功写入的部分。临时分片文件（如 .part001）只是辅助调试，真正续传依据是主文件本身的长度和内容完整性。
立即学习“go语言免费学习笔记（深入）”；
- 启动时先
os.Stat(targetFile)，拿到当前文件大小curSize - 按
curSize / chunkSize算出已成功写满的分片数，剩余未写或写坏的部分才重新发起 Range 请求 - 不要依赖临时文件是否存在来判断进度——它们可能被误删，而主文件只要没被截断就是可信的
- 最后一步校验建议用
sha256.Sum256对完整文件哈希，而不是比对每个分片哈希——网络传输中分片哈希无意义
Range 下载真正的复杂点不在并发控制，而在服务端行为的不可控：状态码飘忽、响应头缺失、实际数据长度不符、中间代理截断……所有这些都得在每次请求后立刻检查，不能攒到合并阶段再处理。
