aiohttp中Range头不生效主因是默认重定向导致头丢失，且CDN/代理常不透传；正确做法是禁用自动重定向、手动处理跳转并携带Range，验证206响应，并严格按Content-Range解析偏移写入文件。
为什么直接加 Range 头在 aiohttp.ClientSession.get() 里不生效？
因为 aiohttp 默认会自动处理重定向（allow_redirects=True），而服务端对带 Range 的请求返回 302 时，后续跳转请求会丢失原始 Range 头——这是最常被忽略的失效原因。另外，部分 CDN 或反向代理（如 Nginx）默认不透传 Range，需显式配置支持。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 必须设置
allow_redirects=False，自己手动处理重定向并携带Range - 检查响应状态码：收到
206 Partial Content才说明服务端真正支持断点续传；若返回200，说明Range被忽略或服务端不支持 - 用
curl -I -H "Range: bytes=0-1023" URL预验服务端行为，比写代码更快定位问题
如何正确构造带 Range 的 aiohttp 请求并拼接分块数据？
关键不是“加个头就完事”，而是要维护已下载字节偏移量、处理 Content-Range 响应头、按需追加写入文件。不能简单用 await resp.read() 全读内存，尤其大文件易 OOM。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
async with aiofiles.open(path, "r+b")以二进制读写模式打开文件，避免覆盖已有内容 - 从
Content-Range响应头解析起始位置：resp.headers.get("Content-Range")形如bytes 1024-2047/100000，提取start = int(match.group(1)) - 写入前调用
f.seek(start)，再await f.write(chunk)，确保落盘位置准确 - 不要依赖
resp.content_length判断是否完成——它可能为None，应比对已写总字节数与Content-Length或预知文件总大小
Range 值怎么算？从 0 开始还是已下载字节数？
必须从已下载的**下一个字节索引**开始，即 Range: bytes=<strong>已写入字节数</strong>-。比如已成功写入 12345 字节，下次请求应设 Range: bytes=12345-（末尾不指定上限，由服务端决定单次返回多少）。
常见错误：
- 误写成
bytes=12345-12345（只请求 1 字节），导致大量小请求、性能骤降 - 未校验服务端实际返回范围，直接按请求范围写入，造成文件错位（例如请求
12345-却返回12345-13344，但代码仍从 12345 写到 13344+1） - 多协程并发请求同一资源时，未加锁更新全局偏移量，导致
Range重复或跳空
有没有更稳的替代方案？aiohttp 断点续传的硬伤在哪？
硬伤在于 aiohttp 不像 requests 那样内置分块流式写入和断点逻辑，所有状态（偏移、重试、重定向头透传）都得手写维护。一旦服务端返回 206 但 Content-Range 格式异常（如漏空格、单位非 bytes），就容易解析失败。
如果项目允许，可考虑：
- 用
httpx.AsyncClient替代：原生支持stream=True和headers透传，重定向时默认保留自定义头（需确认版本 ≥ 0.24.0） - 退回到同步方式 +
threading：对超大文件，用requests分块下载更省心，IO 密集场景下线程池性能损失有限 - 绕过 HTTP 层：改用支持断点的协议（如 FTP、SFTP），或让服务端提供预签名分片 URL（如 S3 presigned URLs）
真正麻烦的从来不是加一行 Range，而是服务端响应不可控、网络中断后偏移量恢复、以及并发写入时的文件游标竞争——这些细节不压测根本暴露不出来。
