Flask默认send_file不适合大文件传输，因其一次性读入内存且存在目录遍历风险；应改用生成器+Response流式响应，配合路径校验、禁用Nginx缓冲等完整链路控制。
Flask 默认的 send_file 和 send_from_directory 会把整个文件读进内存再发出去，1GB 文件就吃掉 1GB 内存——这不是代码写得不好，是默认行为本身就不适合大文件。
为什么不能用 send_file？
它内部调用 f.read() 一次性加载全部内容，生成一个 bytes 对象。哪怕你只传 500MB 的日志压缩包，进程 RSS 就会瞬间飙高，还可能触发 OOM killer 杀死进程。
-
send_file不支持流式 yield，没法控制 chunk 大小 - 无法校验用户请求路径是否越界（比如
../../etc/passwd），存在目录遍历风险 - 返回响应时自动设置
Content-Length，而流式传输不该设这个头（HTTP/1.1 chunked 编码下它是冗余且有害的）
怎么手动构造流式 Response？
核心是用生成器 + Response 构造器，绕过 Flask 封装逻辑。关键点不是“能不能”，而是“每一步是否可控”：
- 用
with open(path, "rb") as f:打开文件，确保句柄及时释放 - 每次
f.read(8192)（8KB）——太小增加系统调用开销，太大浪费内存；实测 8–64KB 是安全区间 - yield chunk 后立刻交给 WSGI server 推送，不缓存、不拼接
-
Response(generator(), mimetype="application/octet-stream")中不要传content_length - 必须加
headers={"Content-Disposition": 'attachment; filename="xxx.zip"'}，否则浏览器可能尝试解析二进制内容导致乱码或崩溃
路径校验和 Nginx 代理陷阱
用户输入的文件名不能直接拼进 open()——../ 会逃逸出根目录。Nginx 更是常见断点：它默认开启 proxy_buffering on，会等整个生成器结束才转发，彻底废掉流式效果。
立即学习“Python免费学习笔记（深入）”；
- 路径校验必须用
os.path.realpath+os.path.commonpath对比白名单根路径，例如：real_path = os.path.realpath(file_path) if os.path.commonpath([real_path, "/var/data"]) != "/var/data": abort(403) - Nginx 配置里对应 location 块必须显式关掉缓冲：
proxy_buffering off; proxy_cache off; proxy_http_version 1.1; proxy_set_header Connection '';
流式不是加个 yield 就完事，它是一整条链：生成器控制读取节奏 → Response 跳过默认封装 → HTTP 头规避 Content-Length → 反向代理禁用缓冲 → 客户端用 stream=True 按需消费。漏掉任意一环，内存节省就归零。
