Flask接收大文件不能直接用request.files读全部内容，因为会将整个文件加载进内存导致内存溢出或被WSGI/Nginx拦截；应禁用自动解析，改用request.stream流式读取，并配合MultiPartParser（max_form_memory_size=0）安全解析分块上传。
Flask接收大文件时为什么不能直接用 request.files 读全部内容？
因为 request.files['file'].read() 会把整个文件加载进内存，1GB 文件就占 1GB 内存，还可能触发 MemoryError 或被 Nginx/WSGI（如 Gunicorn）的请求体大小限制拦截。Werkzeug 默认将小文件暂存为 TemporaryFile，但大文件仍走内存缓冲，不解决根本问题。
真正可行的路径是：禁用自动解析、绕过 request.files，直接从 request.stream 流式读取原始字节，并配合分块逻辑写入磁盘或对象存储。
- 必须在 Flask 配置中关闭文件自动解析：
app.config['MAX_CONTENT_LENGTH'] = None（否则 WSGI 层就截断了） - 需手动设置
Content-Type: multipart/form-data并确保前端带正确的boundary - 不要调用
request.form或request.files，它们会强制消费request.stream，导致后续读取为空
如何用 werkzeug.formparser.MultiPartParser 安全解析分块上传流？
Werkzeug 提供了底层解析器，能边读流边提取字段和文件块，避免整包加载。它不依赖 request.files，适合自定义分块逻辑。
关键点是构造一个只处理当前 chunk 的解析器实例，并指定 max_form_memory_size=0 强制所有数据流式落盘：
from werkzeug.formparser import MultiPartParser
from werkzeug.datastructures import Headers
<h1>假设已从 request.headers 取到 boundary</h1><p>boundary = request.headers.get('Content-Type', '').split('boundary=')[-1]
headers = Headers([('Content-Type', f'multipart/form-data; boundary={boundary}')])</p><p>parser = MultiPartParser(
stream=request.stream,
headers=headers,
max_form_memory_size=0, # 关键：禁用内存缓存
cls=lambda *a: a[0], # 不包装成 ImmutableMultiDict，返回原始字段名+值
)
for field_name, value, filename, content_type in parser.parse():
if field_name == 'chunk':</p><h1>直接 write 到临时文件或 minio 分片</h1><pre class="brush:php;toolbar:false;"> with open(f'/tmp/upload_{upload_id}_part_{part_num}', 'ab') as f:
f.write(value)
part_num += 1
-
max_form_memory_size=0是核心开关，否则 parser 仍可能把小字段塞进内存 - 前端必须按标准 multipart 格式组织每个 chunk，不能用 JSON 封装二进制
- 该 parser 不校验字段顺序，需前端保证
chunk字段连续出现
前端传 chunk 后，后端怎么合并并校验完整性？
合并本身简单，但容易忽略两个关键动作：临时文件权限清理 + 哈希一致性校验。Werkzeug 解析出的每个 chunk 是独立字节块，没有元信息，所以需前端额外传 upload_id、part_number、total_parts、file_hash（如 SHA256）。
- 合并命令建议用
cat /tmp/upload_abc_part_* > /final/file.bin，比 Pythonopen().write()更少内存占用 - 合并后立刻用
hashlib.sha256()计算最终文件哈希，与前端传的file_hash对比，防止网络丢包或分片错序 - 务必在合并成功后才删临时分片，且用
os.unlink()而非os.remove()（前者更原子） - 若用云存储（如 MinIO），应调用
compose_object接口合并，而非下载再上传
为什么 Nginx 默认会破坏分块上传流？
因为 Nginx 的 client_max_body_size 和 client_body_buffer_size 会缓存整个请求体，等收全再透传给 Flask —— 这直接废掉流式读取的意义。
必须在 Nginx 配置中显式禁用缓冲：
location /upload {
client_max_body_size 0; # 允许任意大小
client_body_buffer_size 128k; # 小缓冲区，减少内存驻留
client_body_in_file_only on; # 强制写临时文件，不进内存
client_body_temp_path /var/tmp/nginx_upload;
proxy_pass http://flask_app;
}
-
client_body_in_file_only on是关键，它让 Nginx 把 body 直接落盘，Flask 的request.stream实际读的是这个临时文件 fd - 如果用 Gunicorn，还要加
--limit-request-field_size 0和--limit-request-line 0，否则它也会提前拦截 - 本地开发用 Flask 自带服务器时，这些配置无效，需改用 Gunicorn + Nginx 组合验证流行为
实际部署时，最常被跳过的环节是 Nginx 缓冲配置和 Werkzeug 解析器的 max_form_memory_size=0 设置——这两处任一遗漏，都会让“流式”变成“假装流式”。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
