Python用requests流式下载大文件实战

本文深入剖析了Python中使用requests库安全高效地流式下载大文件的关键实践，直击内存爆炸、连接泄漏、状态码误判和断点续传失效等高频陷阱：必须显式启用`stream=True`并配合`iter_content()`分块读取，合理设置`chunk_size`（推荐8KB–64KB）以平衡性能与内存压力，严格采用`with`语句确保连接自动释放，前置调用`raise_for_status()`避免静默写入错误响应，并手动处理重定向与Range头实现可靠断点续传——每一步细节都决定着数百MB乃至GB级文件下载的成败。

requests.get()不加stream=True会内存爆炸

直接用 requests.get(url) 下载几百MB以上的文件，Python进程会把整个响应体读进内存，容易触发 MemoryError 或让系统卡死。根本原因是默认 stream=False，底层会调用 response.content 一次性加载全部字节。

• 必须显式传 stream=True，让 response 返回一个可迭代的流对象
• 即使加了 stream=True，也得手动调用 response.iter_content(chunk_size=...) 才能分块读取
• 别依赖 response.text 或 response.json() —— 它们会强制读完并解码，完全违背流式初衷

chunk_size设太小或太大都影响性能

分块大小不是越大越好，也不是越小越“安全”。它直接影响I/O次数、内存占用和吞吐效率。

• 默认 chunk_size=1（即每次只读1字节）—— 磁盘写入次数爆炸，CPU空转严重，实测比不流式还慢
• 设成 8192（8KB）或 65536（64KB）是较稳妥的起点，兼顾缓存友好性和内存压力
• 超过 1048576（1MB）后收益递减，且单次分配大缓冲区可能触发GC抖动，尤其在低内存环境
• 如果目标是边下边校验（如计算SHA256），建议用 chunk_size=8192，避免哈希更新延迟过大

忘记response.close()或没用with语句会泄漏连接

流式下载完成后不释放连接，requests底层的 urllib3 连接池会持续占用 socket，反复执行几次就可能报 ConnectionError: Max retries exceeded 或卡在 Connecting 状态。

• 最可靠写法是用 with requests.get(..., stream=True) as response: —— 自动调用 response.close()
• 手动调用时，必须确保 response.close() 在 finally 块里执行，哪怕遇到异常或提前 break
• response.raise_for_status() 要放在 with 块内，否则异常抛出后连接可能没关干净

重定向和HTTP状态码处理容易漏掉

很多大文件URL实际是302跳转到CDN地址，而默认 requests.get() 会自动跟随重定向——但如果你没检查最终响应状态，可能下到一个403/404页面却浑然不觉。

• 加 allow_redirects=False 可以先捕获跳转，再决定是否手动跟进（比如需要记录真实URL）
• 务必在循环读取前调用 response.raise_for_status()，否则 4xx/5xx 响应体也会被当作文件内容写入磁盘
• 有些服务对无 User-Agent 的请求返回 403，记得加 headers：{"User-Agent": "Mozilla/5.0"}
• 下载中断后想续传？标准 requests 不支持 Range 头自动恢复，得自己构造 headers={"Range": "bytes=1024-"} 并处理 206 响应

真正麻烦的不是怎么写完，而是怎么确保断点能续、内存不爆、连接不积压、错误不静默——这些细节全在 stream、chunk_size、with 和 raise_for_status() 几个地方卡着。

今天关于《Python用requests流式下载大文件实战》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！