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 封装逻辑。关键点不是“能不能”，而是“每一步是否可控”：

Claw Code Suite (Python-Only Edition)

仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...

下载

• 用 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，会等整个生成器结束才转发，彻底废掉流式效果。

• 路径校验必须用 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 按需消费。漏掉任意一环，内存节省就归零。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！