Go大文件多线程下载核心卡点是服务端Range支持校验、分块对齐、WriteAt原子写入；必须HEAD双重验证Accept-Ranges与206响应，固定块大小分片（如1MB），预分配文件空间后用WriteAt精准写入，避免os.O_APPEND或Seek+Write。
Go 语言大文件多线程下载不是“开几个 goroutine + Range 头就行”，核心卡点在服务端支持校验、分块对齐、写入原子性三处。跳过任一环节，文件大概率损坏或静默错位。
如何用 HEAD 验证服务端是否真支持 Range
Accept-Ranges: bytes 这个响应头可以伪造，光看它没用。必须发 HEAD 请求后做双重验证：
- 检查
resp.StatusCode是 200（非 206）——说明服务器忽略 Range，直接退化单连接 - 检查
resp.Header.Get("Accept-Ranges") == "bytes"且resp.Header.Get("Content-Length")非空 - 再补一个试探性 GET：加
Range: bytes=0-1023，看响应码是否为206 Partial Content，且Content-Range头匹配（如bytes 0-1023/12345678） - 若任意一项失败，别硬上并发，老老实实走单连接
io.Copy
分块时为什么不能用 fileSize / goroutineCount 均分
整除余数会导致最后一块为 0 字节，或者某段起始 > 结束；更隐蔽的问题是：某些 CDN（如 Cloudflare 默认配置）会截断非对齐的 Range（比如末尾带奇数字节），返回 416 或 200 全量内容。
- 固定块大小（如
1024 * 1024即 1MB）比均分更稳 - 每段
to偏移必须写成min(start + chunkSize - 1, fileSize - 1)，防止越界 - 起始偏移无需强制对齐（
from % chunkSize == 0不是必须），但对齐后方便用cmp或Beyond Compare校验加密/压缩文件 - 避免块大小小于 64KB——太小会触发 HTTP/1.1 连接复用抖动，实际吞吐反而下降
WriteAt 写入前为什么必须预分配文件空间
多个 goroutine 并发调用 file.WriteAt 时，如果目标文件尚未达到最终大小，Linux 下扩展文件的操作（如隐式增长）不是原子的，可能造成稀疏区域或写入失败。
立即学习“go语言免费学习笔记（深入）”；
- 先用
os.Truncate(file, fileSize)或file.WriteAt(make([]byte, 1), fileSize-1)强制拉伸文件 - 绝对不要用
os.O_APPEND——它和WriteAt行为冲突，会无视偏移量强行追加 - 也别用
file.Seek() + file.Write()，因为Seek是共享状态，goroutine 间无法保证顺序 - 每个 goroutine 独立持有自己的
start和end，直接file.WriteAt(buf, int64(start))
临时块文件 vs 直接 WriteAt：什么场景该选哪种
WriteAt 适合服务端稳定、网络质量好、内存充足的情况；临时块文件（如 file.zip.001.part）更适合生产环境容错。
- 临时块方案：每个 goroutine 写独立文件，合并时用
io.Copy流式拼接，不占内存；崩溃后可重试单块，不污染主文件 - WriteAt 方案：省磁盘 IO，但一旦某个 goroutine panic 或网络中断，文件可能处于中间态，需额外记录已写区间做恢复
- 跨文件系统合并时，
os.Rename不再原子，必须file.Sync()后再os.Remove旧文件 - 真正容易被忽略的是：HTTP/2 下多个 Range 请求可能被复用同一连接而串行化，得显式禁用：
&http.Transport{ForceAttemptHTTP2: false}
