requests.get() 默认将响应体全部加载到内存，大文件易导致OOM；应使用stream=True流式下载，配合iter_content分块写入磁盘，并配置超时、重试与连接复用以增强健壮性。
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，显式控制：
立即学习“Python免费学习笔记（深入）”；
- 用
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，别盲目重试所有错误
流式下载真正的复杂点不在“怎么读”，而在“怎么扛住网络抖动、服务不稳定、磁盘慢、权限变化”。这些地方一漏，程序跑半小时崩在最后一分钟，查起来反而更费时间。
