Go大文件多点下载需先HEAD校验Accept-Ranges和Content-Length，不支持则退化单连；分块须对齐、用临时文件+原子合并，避免损坏错位。
Go 语言实现大文件多点下载（即多连接、分块并发下载），核心不是“开更多 goroutine 就行”，而是必须配合 Range 请求、偏移量对齐、临时块管理与原子合并——否则极易出现文件损坏、块错位或状态丢失。
HTTP Range 请求必须校验服务端支持
不是所有服务器都响应 206 Partial Content，强行发 Range 头可能返回 200 全量内容或直接 416 错误。
- 先用
HEAD请求检查响应头：Accept-Ranges: bytes是必要条件；Content-Length必须存在才能算出总大小 - 若
Accept-Ranges缺失或值为none，退化为单连接下载，不要硬分块 - 某些 CDN 或反向代理（如 Nginx 默认配置）会忽略或截断
Range，需显式开启underscores_in_headers on并确认slice模块启用
分块策略要避开边界错位和小块抖动
按线程数均分字节范围看似简单，但实际容易因整除余数、文件系统对齐、网络 MTU 导致最后一块写入失败或覆盖。
- 推荐以固定块大小（如
1 ，即 1MB）切分，而非严格按 <code>fileSize / threads计算 - 每个块的
to偏移应设为min(start + chunkSize - 1, fileSize - 1)，避免越界 - 起始偏移必须对齐：
from % chunkSize == 0不是必须，但能减少调试时 Beyond Compare 等工具比对困难（尤其涉及加密/压缩文件） - 不要让任意一块大小
临时块文件必须独立命名+原子合并
多个 goroutine 同时写同一个文件（哪怕用 os.O_APPEND）在 Linux 下不保证原子性，POSIX 只保证单次 write() 原子，不保证多进程/协程追加顺序。
立即学习“go语言免费学习笔记（深入）”；
- 每个 goroutine 下载后写入唯一临时路径，如
output.zip.001.part、output.zip.002.part - 合并时按序读取各
.part文件，用io.Copy流式写入最终文件，不要os.ReadFile全加载进内存 - 合并完成后调用
os.Rename替换目标文件——该操作在同文件系统下是原子的；若跨磁盘，需先sync再os.Remove - 务必在
defer或recover中清理未完成的.part文件，否则残留块会干扰下次下载
并发控制与错误恢复不能只靠 sync.WaitGroup
WaitGroup 只能等结束，无法应对超时、重试、部分失败等真实场景。
- 用带缓冲的
chan error收集每个 goroutine 的错误，任一失败就中断全部下载（除非明确支持容错续传） - 每个下载任务应封装超时：
http.Client{Timeout: 30 * time.Second}，且设置Transport.MaxIdleConnsPerHost = 100防连接池耗尽 - 记录每个块的完成状态到本地（如 JSON 文件或 SQLite），重启后可跳过已成功块，而不是从头开始
- 不要用
runtime.NumCPU()直接当并发数——网络 IO 密集型任务通常 4–8 即可，过多反而触发 TCP 拥塞或服务端限流
真正难的不是并发本身，而是如何让每个块的 from/to 在中断、重试、合并后仍严丝合缝；一旦某块写偏 1 字节，整个文件就不可用。所以别省略校验步骤：合并后至少做一次 os.Stat 总长比对，有条件再加 SHA256。
