requests.get()必须加stream=True防内存爆炸，配合iter_content分块读取、with自动关闭连接、raise_for_status检查状态、合理设置chunk_size（如8192），并手动处理重定向和断点续传。
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页面却浑然不觉。
立即学习“Python免费学习笔记（深入）”；
- 加
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() 几个地方卡着。
