断点续传需先用HEAD获取Content-Length和Accept-Ranges: bytes，再构造合法Range头发起stream=True请求；响应必须为206，写入用"ab"模式并flush/fsync；并发下载需预分配文件并按偏移顺序写入；遇416需校准分块边界。
如何用 requests 发起带 Range 头的分块请求
断点续传本质是让服务器只返回文件某一段字节，关键在 HTTP Range 请求头。Python 的 requests 支持直接传入 headers，但必须确保服务器返回 206 Partial Content（而非 200），否则说明服务端不支持断点续传。
常见错误：没检查响应状态码就写入文件，导致重复覆盖或乱序拼接；或者传了 Range 但服务器忽略，仍返回完整文件。
- 先用
HEAD请求获取Content-Length，确认文件总大小 - 检查响应头中是否有
Accept-Ranges: bytes，这是服务端支持分段下载的明确信号 - 构造
Range时格式必须为"bytes=0-1023"，不能多空格、不能漏单位 - 务必用
stream=True，避免一次性加载整个 chunk 到内存
如何安全地追加写入已存在的临时文件
本地文件可能已存在部分数据，续传时不能清空重写，而要用 "ab" 模式打开——追加二进制写入。但要注意：如果上次中断发生在写入中途（比如刚写了一半就崩溃），文件末尾可能残留脏数据，直接续传会错位。
更稳妥的做法是：记录每个分块的起始偏移和实际写入长度，在恢复前校验最后一块是否完整。不过对大多数场景，简单策略更实用：
立即学习“Python免费学习笔记（深入）”；
- 用独立的
.download后缀保存临时文件（如file.zip.download），下载完成后再os.replace()重命名 - 每次写入前用
fp.seek(offset)定位，而不是依赖文件当前大小——因为os.path.getsize()可能不准（如 NFS 或某些挂载文件系统） - 写入后立即调用
fp.flush()和os.fsync(fp.fileno())，防止内核缓存未落盘导致断电丢数据
怎么管理多个并发分块并保证顺序拼接
并发下载多个 Range 块能提升速度，但写入必须按偏移顺序。不能让线程 A 写 10KB–20KB、线程 B 写 0–10KB，结果 B 晚写完导致开头数据被覆盖。
推荐用 concurrent.futures.ThreadPoolExecutor + 预分配文件 + 线程安全写入：
- 先用
os.truncate()把文件扩展到最终大小（需有写权限），避免写入时频繁扩容影响性能 - 每个 worker 下载完一块后，把
(offset, data)放入queue.Queue或存入list，主线程按offset排序后统一写入 - 更轻量的做法：每个线程自己打开文件、
seek()到对应位置再写，只要确保写入区间不重叠且seek+write是原子的（在大多数本地文件系统上成立） - 注意 Windows 上文件不能被多个进程同时写，但同进程多线程可以
遇到 416 Range Not Satisfiable 怎么办
这个错误表示你请求的字节范围超出了文件实际大小，比如服务器返回 Content-Length: 10000，但你的请求是 Range: bytes=9999-19998，最后一块算多了 1 字节。
根本原因是分块计算没对齐：比如用 chunk_size = 1024*1024 分 10MB 文件，最后一块本应是 bytes=9437184-9999999，但代码误算成 9437184-10485759。
- 计算每块结束位置时，用
min(start + chunk_size - 1, total_size - 1)，不是start + chunk_size - 1 - 别依赖
Content-Range响应头里的*/12345部分来更新总大小——它可能不准确，应以首次HEAD获取的Content-Length为准 - 某些 CDN 或代理会改写
Content-Range，甚至把206降级成200，此时需回退到单连接全量下载
分块逻辑看似简单，但偏移计算、文件定位、异常恢复三者稍有错位，下载出来的文件就打不开。最易被忽略的是：没验证服务端是否真支持 Range，就默认走断点逻辑。
