直接用requests.get()无法断点续传，因默认不带Range头，服务端返回完整文件而非指定范围；需先HEAD检查Accept-Ranges支持，再手动添加Range头、以'ab'模式追加写入，并严格校验206状态码。
为什么直接用 requests.get() 无法断点续传
因为默认请求不带 Range 头，服务端就当全新请求处理，返回完整文件 —— 即使本地已下了一半，也会重头开始，浪费带宽和时间。关键不是“能不能分片”，而是“服务端是否支持 Range 请求”。先用 curl -I URL 检查响应头里有没有 Accept-Ranges: bytes 或 Content-Range 字段，没有就别硬搞断点，得换源或走其他协议（如 FTP）。
用 requests 发起分片请求并追加写入
核心是手动构造 headers={'Range': 'bytes=1024-2047'}，再以 'ab' 模式打开文件（注意不是 'wb'），确保每次只写对应片段。常见错误包括：
-
Range值算错：起始偏移从 0 开始，结束偏移要包含在内（bytes=0-1023是前 1024 字节） - 没校验响应状态码：成功应是
206 Partial Content，收到200说明服务端忽略Range，得降级为全量下载 - 多线程并发写同一文件易乱序：必须按分片顺序写，或用临时文件 + 合并，或加锁控制写入顺序
示例逻辑：
headers = {'Range': f'bytes={start}-{end}'}
resp = requests.get(url, headers=headers, timeout=30)
if resp.status_code == 206:
with open(filename, 'ab') as f:
f.write(resp.content)
如何记录与恢复下载进度
不能靠文件大小反推进度（可能被其他程序修改），必须独立存一个元数据文件，比如 xxx.downloading.json，里面至少记：url、total_size（首次 HEAD 获取）、downloaded_bytes、last_modified（防服务端更新）。每次启动先读这个文件，对比 url 和 last_modified 是否一致，不一致就清空重下。
立即学习“Python免费学习笔记（深入）”；
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
容易被忽略的点：
-
total_size必须从HEAD响应的Content-Length读，不是靠Content-Range解析（后者在首次请求时不存在） - 写元数据文件要用原子操作：先写临时文件，再
os.replace()覆盖，避免中断导致元数据损坏 - 不要把分片信息（如每个块的 start/end）全存下来 —— 只需当前总进度，分片策略运行时动态计算更轻量
大文件分片下载的线程与内存权衡
分片数不是越多越好。requests 默认不复用连接，开 10 个线程就是 10 个 TCP 连接，服务端可能限流或拒绝；单片太小（如 64KB）会导致 HTTP 头开销占比过高；单片太大（如 100MB）又失去断点灵活性且内存占用陡增。
建议参数组合：
- 单片大小：1–5 MB（视网络稳定性调整，弱网选小值）
- 并发数：3–6（HTTP/1.1 下 6 是较安全上限；若服务端支持 HTTP/2，可适度提高）
- 超时设置：用
timeout=(3, 30)（3 秒连通，30 秒读取），避免卡死线程
真正麻烦的是异常恢复：某个分片失败后，不能简单跳过，必须重试 —— 但重试次数要限制（如 3 次），否则卡住整个流程。重试间隔建议指数退避，比如第 1 次等 1 秒，第 2 次等 2 秒，第 3 次等 4 秒。
