开启流式响应需显式设置 stream=True，使用 iter_lines() 处理换行分隔文本流（如SSE），iter_content() 处理二进制流，务必用 with 语句或手动 close() 释放连接。
requests.get() 怎么开启流式响应
关键在 stream=True 参数，不加它默认会把整个响应体缓存在内存里，哪怕你只想要前几行。加上后，response.raw 才是可迭代的原始 socket 流，response.iter_lines() 和 response.iter_content() 才真正“流起来”。
常见错误是开了 stream=True 却还调用 response.text 或 response.json() —— 这会强制读完全部内容并关闭连接，完全失去流式意义。
- 必须显式设置
stream=True，没有默认值 - 不要访问
.text、.json()、.content，它们会触发完整读取 - 若需解码文本（比如 UTF-8），优先用
iter_lines(decode_unicode=True)，而不是自己对iter_content()做.decode()
用 iter_lines() 处理按行返回的流（如 SSE、日志接口）
iter_lines() 适合服务端用换行分隔的格式，比如 Server-Sent Events（SSE）、纯文本日志流、CSV 行流。它自动处理换行符（\n、\r\n），但注意：每行末尾的换行符会被剥离，且空行会返回空字节串 b''（若未设 decode_unicode=True）。
典型误用是直接 for line in response.iter_lines(): process(line)，却没考虑连接中断或超时重连。真实场景中建议包一层异常捕获和重试逻辑。
- 加
decode_unicode=True得到str而非bytes，避免手动 decode 出错 - 设
chunk_size参数（如iter_lines(chunk_size=1024)）可控制每次从 socket 读多少字节，影响延迟与内存占用 - 遇到
ConnectionError或ChunkedEncodingError时，流可能已断，需重建请求
用 iter_content() 控制二进制块读取（如大文件下载、音频流）
当响应不是文本行结构，而是连续二进制流（如 MP3、视频片段、protobuf 流），就得用 iter_content()。它按字节块返回 bytes，不作任何换行或编码处理，完全交由你解析。
容易忽略的是 chunk_size 的实际影响：太小（如 1）导致频繁系统调用，性能差；太大（如 10MB）又可能卡住主线程或撑爆内存。合理值取决于网络延迟和下游处理能力，通常 8KB–64KB 较稳妥。
-
iter_con是较平衡的起点
tent(chunk_size=8192)
- 若要边下边写入文件，直接传给
file.write()，别拼接成大 bytes 再写 - 注意
response.headers.get('content-length')可能缺失（如 chunked transfer encoding），不能依赖它做进度预判
流式响应必须手动关闭连接吗
必须。requests 不会在你停止迭代后自动关闭底层连接，尤其在出错或提前 break 时。不关会导致 socket 耗尽、连接复用失效、甚至服务端持续发送数据无人接收。
最稳妥方式是用 with requests.get(..., stream=True) as r: —— 它保证无论是否异常、是否读完，都会调用 r.close() 并释放连接。如果不用上下文管理器，务必在 finally 块里显式调用 response.close()。
另一个隐藏坑是：某些代理或 CDN 会缓冲流式响应，即使你 close 了 client 端，服务端仍可能继续发数据，这时得靠服务端配合支持断连信号（如 HTTP/2 RST_STREAM）。
