Python流式下载内存优化技巧

Python流式下载看似简单，实则暗藏内存爆炸、磁盘写满、连接静默中断、重定向失效、压缩干扰等多重陷阱——不加`stream=True`会直接将数百MB响应体全塞进内存引发OOM；开了流又需避开`.content`/`.json()`等“甜蜜陷阱”，用`iter_content(8192)`平衡性能与稳定性，借`shutil.copyfileobj()`防御IO异常，并配合空闲超时监控与精准重试策略，才能真正实现健壮、可控、生产就绪的大文件下载。

requests.get() 不加 stream=True 会吃光内存

直接用 requests.get("https://big-file.com/data.zip") 下载大文件，响应体默认全部加载进内存，哪怕文件 500MB，Python 进程 RSS 就可能瞬间涨到 600MB+，还容易触发 OOM。这不是 bug，是 requests 的默认行为——它得帮你把 response.content 准备好。

必须显式打开流模式：requests.get(url, stream=True)。这之后 response.content 不再可用（会触发读取整个响应的副作用），你得靠 response.iter_content() 或手动调 response.raw 分块读。

• 不加 stream=True：适合小响应（10MB，就别碰
• 加了之后：必须自己管理读取循环，不能依赖 .json() 或 .text（它们会强制读完）
• 注意：HTTP 重定向（302）默认会被 requests 自动跟随，且跟随后的响应也受 stream=True 控制——这点常被忽略，导致你以为开了流，其实重定向后又全载入了

iter_content(chunk_size=8192) 是最稳的分块读法

response.iter_content() 是 requests 官方推荐的流式读取方式，比直接读 response.raw 更安全：它自动处理压缩（如 gzip）、解码、连接中断重试逻辑（在 chunk 级别）。

关键在 chunk_size 参数——不是越大越好，也不是越小越省。实测 8KB（8192）是多数场景下的甜点值：

• chunk_size=1：系统调用太频繁，CPU 负担翻倍，吞吐反而下降
• chunk_size=1024*1024（1MB）：单次分配大 buffer，GC 压力大；网络抖动时，一整块卡住，延迟感知明显
• chunk_size=8192：平衡内存占用、系统调用次数和缓存友好性；SSD/HDD 写入也更顺
• 如果目标是边下边解压（如 tar.gz），建议保持 chunk_size 为 8192，并用 zlib.decompressobj() 流式解压，不要攒满再解

用 shutil.copyfileobj() 替代手动 write() 更可靠

很多人写流式下载，习惯这么干：

for chunk in response.iter_content(8192):
    f.write(chunk)

看起来没问题，但漏掉了两个现实问题：磁盘满、权限拒绝。这些错误在 f.write() 时才抛，而此时 chunk 已经从 socket 读出、丢在内存里了——你没法优雅回退。

shutil.copyfileobj() 内部做了缓冲区复用，且对 IOError 更敏感，更重要的是：它支持传入 length 参数控制总拷贝上限，能防磁盘爆满。

• 正确写法：shutil.copyfileobj(response.raw, f, length=8192)
• 必须用 response.raw（不是 response），否则压缩中间层可能干扰
• 确保 f 是以 wb 模式打开的，且没开 buffering（buffering=0 在二进制模式下无效，别试）
• 如果要校验 hash，别在写入时算——先写临时文件，写完再 hashlib.blake2b(f.read())，避免 IO 和 CPU 绑死

超时和重试必须分开配，别只设 timeout=(3, 30)

timeout=(3, 30) 只控制单次请求的 connect + read 超时，对流式下载几乎没用：read 超时是从第一个字节开始计，但大文件传输中，可能前 10 秒有数据，后面卡住 2 分钟——这时 timeout 不会中断。

真正需要的是「空闲超时」+ 「重试策略」：

• 用 requests.adapters.HTTPAdapter(pool_connections=10, pool_maxsize=10, max_retries=3) 配连接池和重试
• 手动监控读取间隔：记录上一次 iter_content() 返回非空 chunk 的时间，超过 60 秒无新数据，就主动 response.close() 并重试
• 别依赖 requests.packages.urllib3.util.retry.Retry 的 status_forcelist 来重试 503——流式响应一旦发了 header，503 就不会来了，得靠空闲检测

流式下载的麻烦不在代码长短，而在边界是否被想全：网络断了怎么续、磁盘满了怎么停、服务端悄悄关连接你怎么感知。这些没写进文档，但每次上线都会撞上。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。