go中http.client发range请求总返回200而非206，因服务端不支持断点续传或未正确设置range头；http/1.1允许服务端忽略range并返回200，仅当明确支持且范围合法时才返回206。
Go 中用 http.Client 发起 Range 请求为什么总返回 200 而不是 206
因为服务端不支持断点续传，或者你没正确设置 Range 请求头。HTTP/1.1 规定：服务端收到带 Range 的请求后，可选择忽略并返回完整资源（200）；只有明确支持且范围合法时才返回 206 Partial Content。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先用
curl -I -H "Range: bytes=0-1023" https://example.com/file.zip检查响应头是否含Accept-Ranges: bytes和状态码206 - Go 中必须手动设置请求头：
req.Header.Set("Range", "bytes=0-1023")，http.Get不会自动加 - 别依赖
resp.StatusCode == 206做逻辑分支——要同时检查resp.Header.Get("Content-Range")是否非空
用 sync.WaitGroup 控制并发下载分块时常见 panic 场景
典型表现是 panic: sync: WaitGroup is reused before previous Wait has returned，本质是多个 goroutine 重复调用 wg.Add() 或在 wg.Wait() 后又调用了 wg.Add()。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
wg.Add()必须在启动 goroutine 之前、且只调用一次（比如循环前算好总块数，wg.Add(totalChunks)） - 每个 goroutine 结束时只调用
wg.Done()，不要在 defer 里写wg.Add(-1)这类错误操作 - 如果下载失败需重试，别在 goroutine 内直接再调
wg.Add(1)——改用 channel 回传失败块号，由主 goroutine 统一补发
文件写入时多个 goroutine 并发写同一 *os.File 导致内容错乱
Go 的 *os.File.Write() 不是线程安全的，即使指定了偏移量，底层 write 系统调用仍可能因内核缓冲区竞争而覆盖彼此数据。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 绝对不要让多个 goroutine 直接调
file.Write()—— 改用file.WriteAt(data, offset)，它内部会做原子 seek+write - 但注意：Windows 下
WriteAt可能慢于 Linux，且某些 NFS 文件系统不完全支持，上线前务必实测 - 更稳妥的方式是每个 goroutine 写入内存 buffer（
[]byte），全部完成后按顺序拼接再一次性写盘，适合小文件或内存充足场景
计算分块大小时 Content-Length 和实际可切分范围不一致
比如服务端启用了 gzip 压缩，但没透传原始长度；或者 CDN 缓存了压缩后的内容，导致 Content-Length 小于真实文件尺寸，按它切块会漏数据。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先用 HEAD 请求获取
Content-Length，但必须配合Accept-Ranges: bytes验证有效性 - 若不确定服务端行为，改用 GET +
Range: bytes=0-获取完整响应头中的Content-Range字段（如bytes 0-9999/12345678），从中解析总大小 - 分块大小别硬写
1024*1024—— 大文件建议按总大小 / 并发数向上取整，避免最后一块过小引发频繁 syscall
Range 请求看着简单，但服务端兼容性、文件系统特性、Go 运行时调度三者叠加，很容易在压测时才暴露竞态。最保险的做法是：先单线程跑通 Range + WriteAt 流程，再加并发，最后补失败重试和校验逻辑。
