Python爬虫下载大文件方法详解

本文深入剖析了Python中使用requests库安全高效下载大文件的核心技巧，直击默认全量加载导致内存溢出（OOM）的痛点，强调必须启用stream=True配合iter_content分块读取与二进制流式写入，同时系统性地解决了断点续传风险、Content-Length不可靠、超时机制不合理、连接复用缺失及网络异常重试等生产环境常见陷阱，为开发者提供了一套兼顾健壮性、可观测性与资源可控性的工业级下载方案。

requests.get() 默认会把整个文件读进内存，大文件直接 OOM

你用 requests.get("https://example.com/big.zip") 下载几百 MB 的文件，Python 进程内存可能瞬间飙到 1GB+，甚至被系统 kill。这不是网络问题，是 requests 默认把响应体全部缓存在内存里，等你调用 .content 或 .text 才吐出来——对大文件来说，这一步已经晚了。

真正要做的，是关掉自动响应体解码 + 手动流式读取：

• 加参数 stream=True，让 requests.get() 返回一个未读取的响应对象
• 绝不能碰 .content、.json()、.text，它们会强制加载全部响应体
• 用 .iter_content(chunk_size=8192) 分块读，每次只拿几 KB 到内存

如何安全地边下载边写入磁盘（避免断电/中断丢数据）

直接 f.write(r.content) 是最常见错误——它又把整份内容拉进内存了；而用 iter_content() 写文件时，如果没处理好异常或没 flush，可能写一半就退出，得到一个损坏的文件。

稳妥做法是：用二进制模式打开文件 + 每次写 chunk 后不依赖自动 flush，显式控制：

• 用 with open("out.bin", "wb") as f: 确保文件句柄自动关闭
• 循环中用 for chunk in r.iter_content(chunk_size=8192): f.write(chunk)
• 不需要手动 f.flush()，但务必确认 chunk 非空（有些服务器会在末尾返回空 chunk，跳过即可）
• 加上 try/except 捕获 requests.exceptions.RequestException 和 IOError，失败时删掉不完整文件

response.headers.get("content-length") 不一定可信

你想预估下载进度？别全信 response.headers.get("content-length")。很多 CDN、反向代理、动态生成的文件（比如导出报表）根本不会发这个 header，或者返回 -1、空字符串、甚至错误值。

更现实的做法是：只在它存在且为正整数时用，否则降级为“未知大小”进度条：

• 用 int(r.headers.get("content-length", 0)) 转换，捕获 ValueError
• 检查是否 > 0，否则设为 None，后续逻辑分支处理
• 别用它做校验——文件写完后用 os.path.getsize() 对比更可靠

超时、重试、连接复用这些细节比流式本身更容易翻车

流式下载跑着跑着卡住不动？大概率不是代码逻辑问题，而是默认 timeout 太短，或没配连接池，导致中间 TCP 连接静默断开。

关键配置必须显式设：

• timeout=(3.05, 27)：分开放 connect timeout 和 read timeout，后者得足够长（比如 20–30 秒），否则大文件传输中只要停顿超过默认 3 秒就报 ReadTimeout
• 用 requests.Session() 复用连接，避免每请求重建 TCP，尤其批量下载时明显提速
• 加简单重试：用 urllib3.util.Retry 配合 Session，重点重试 ConnectTimeout 和 ProtocolError，别盲目重试所有错误

流式下载真正的复杂点不在“怎么读”，而在“怎么扛住网络抖动、服务不稳定、磁盘慢、权限变化”。这些地方一漏，程序跑半小时崩在最后一分钟，查起来反而更费时间。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~