Flask流式返回大文件卡住或内存不降，因默认响应缓存整个生成器内容；需返回生成器对象、设direct_passthrough=True、禁用Content-Length、换gunicorn/uWSGI、Nginx关proxy_buffering并调优。
Flask 里用 yield 返回大文件为什么会卡住或内存不降？
因为默认 Flask 响应会把整个生成器内容攒在内存里转成字符串再发出去，哪怕你写了 yield，底层 WSGI 服务器（比如 Werkzeug 开发服务器）也可能缓冲整块响应。结果就是：文件没传完，内存先爆了，浏览器也一直转圈。
- 确保视图函数返回的是生成器对象，不是调用后的列表（别写
return list(generator)） - 必须设置
Response的direct_passthrough=True，否则 Flask 会试图读取全部内容做编码检测 - 加上
Content-Length头会让部分客户端提前知道大小，但大文件往往没法预知长度，此时宁可不设，也不要瞎填 - 开发时用
flask run启动的服务器对流支持很弱，上线前务必换gunicorn或uWSGI，并确认启用了--preload和流式中间件
怎么写一个真正流式返回大文件的 Flask 路由？
核心是绕过 Flask 默认响应封装，手动构造 Response，并让生成器按 chunk 拉取、即时写出。不能依赖 send_file 或 send_from_directory —— 它们内部会 open().read() 整个文件。
- 用
with open(path, "rb") as f:打开文件，每次yield f.read(8192)（8KB 是较稳妥的 chunk 大小） - 返回
Response(generator, mimetype="application/octet-stream")，不要加content_length - 务必设
headers={"Content-Disposition": 'attachment; filename="bigfile.zip"'}，否则浏览器可能尝试渲染二进制内容 - 如果路径来自用户输入，必须用
os.path.realpath+os.path.commonpath校验是否越界，防止目录遍历
def stream_file():
path = "/var/data/large-backup.tar.gz"
def generator():
with open(path, "rb") as f:
while True:
chunk = f.read(8192)
if not chunk:
break
yield chunk
return Response(generator(), mimetype="application/octet-stream",
headers={"Content-Disposition": 'attachment; filename="backup.tar.gz"'})
为什么 Nginx 会吃掉你的流式响应？
Nginx 默认开启 proxy_buffering on，它会等后端整个响应结束才往客户端推，彻底废掉你的 yield。这不是 Flask 的锅，是反向代理拦住了流。
- 在 location 块里加
proxy_buffering off;，同时配proxy_cache off; - 必须设
proxy_http_version 1.1;和proxy_set_header Connection '';，否则 HTTP/1.0 连接会被强制关闭 - 如果用了
gzip on，Nginx 会等完整响应才能压缩，直接关掉：gzip off;（压缩应由应用层或 CDN 完成） - 测试时 curl 加
-N参数禁用缓冲，看是否真有数据分批出来：curl -N http://localhost/download
生成器抛异常时响应中断怎么办？
生成器中途出错（比如文件被删、权限变掉），Flask 不会自动返回 500，而是断连或返回空响应，前端卡死无提示。
立即学习“Python免费学习笔记（深入）”；
- 在生成器内部包
try/except，捕获IOError、OSError等，并yield一段错误信息字节（如b"ERROR: file missing"），再raise - 更稳的做法是先校验文件存在且可读：
if not os.path.isfile(path) or not os.access(path, os.R_OK): abort(404) - 别在生成器里做耗时操作（如数据库查询、网络请求），每个
yield都该是纯 IO 读取，否则延迟会累积 - 超时控制靠 WSGI 服务器（如 gunicorn 的
--timeout）和 Nginx 的proxy_read_timeout，前后端要对齐
yield 就完事，从 Python 生成器、WSGI 中间件、反向代理到浏览器接收，每层都可能缓存或截断。最容易被忽略的是 Nginx 配置和开发服务器的假流式表现——本地跑通不等于线上可用。 
