怎样在Python Flask中实现多文件并发上传_处理request.files对象-Python教程-PHP中文网

flask中request.files是只读的immutablemultidict，需用getlist('name')获取文件列表，配合secure_filename()校验文件名、白名单检查扩展名，并用线程/进程池卸载io/cpu耗时操作，生产环境须换gunicorn+gevent等并发服务器。

怎样在python flask中实现多文件并发上传_处理request.files对象

Flask中request.files是ImmutableMultiDict，不能直接遍历修改

很多人一上来就写 for f in request.files: 或尝试 request.files.pop()，结果报 RuntimeError: immutable。这是因为 Flask 的 request.files 是只读的 ImmutableMultiDict，底层不允许增删改。它设计上就是“接收即冻结”，你要处理多个文件，得先转成可操作结构。

正确做法是用 request.files.getlist('file') —— 注意参数名必须和前端 <input type="file" name="file" multiple> 中的 name 一致。如果前端用了不同 name（比如 name="uploads"），这里就必须写 getlist('uploads')，否则返回空列表。

不推荐用 list(request.files.values())：可能漏掉同名多文件（浏览器上传时若用 multiple，所有文件共享一个 key）
不要对 request.files 做任何赋值或 del 操作，会直接抛异常
如果前端没加 multiple 属性，即使选了多个文件，request.files 也只保留最后一个

并发处理多个上传文件需绕过Flask默认同步I/O阻塞

Flask 默认是同步 WSGI 服务器（如 Werkzeug dev server），request.files 解析本身是阻塞的，但真正耗时的是后续保存、压缩、OCR 等操作。如果你在视图函数里逐个调用 f.save() 或做 CPU 密集型处理，整个请求线程就被卡住，无法并发响应其他上传请求。

解决思路不是“让 Flask 并发读 files”，而是把耗时操作移出主线程。最轻量的做法是用 concurrent.futures.ThreadPoolExecutor，尤其适合 I/O 密集型任务（如写磁盘、调外部 API）；如果是 CPU 密集型（如图像缩放），则考虑 ProcessPoolExecutor，但要注意文件对象不能跨进程传递，得先保存到临时路径再传路径字符串。

Li Python Sec Check

Python 安全规范检查工具：基于 CloudBase 规范、腾讯安全指南，LLM 智能分析（默认禁用，优先本地执行）

下载

别在主线程里用 time.sleep() 或长循环模拟处理，这会让整个 Flask 进程假死
不要在多线程里直接操作 request 对象（它是线程局部的），所有文件数据必须在进入线程前完成读取或保存
使用 f.read() 提前加载内容到内存时，注意大文件会导致内存暴涨，建议配合 f.stream.read(chunk_size) 流式处理

保存文件前必须校验filename防止路径穿越

request.files.getlist() 返回的每个 FileStorage 对象都有 filename 属性，但它完全由客户端控制，可被恶意篡改为 ../../etc/passwd。Flask 不做自动净化，你必须手动处理。

标准做法是用 werkzeug.utils.secure_filename() —— 它会删掉路径分隔符、控制字符和非 ASCII 字符，只保留 ASCII 字母、数字、下划线和点。但要注意：它不检查空 filename、不防重名、不验证扩展名是否合法。

空 filename 表示用户没选文件，应跳过或报错，而不是生成空文件名
即使用了 secure_filename()，也要额外检查扩展名是否在白名单中（如 ['.jpg', '.png', '.pdf']），避免上传 .py/.html 绕过
不要拼接用户原始 filename 到绝对路径里，比如 os.path.join('/uploads', f.filename) 是危险的

生产环境别用Werkzeug开发服务器跑多文件上传

本地调试时用 flask run 没问题，但它的 Werkzeug 服务器是单线程单进程，面对多个并发上传请求会排队等待，看起来像“卡住”。真实场景下，上传请求常伴随大文件和慢网络，极易拖垮服务。

上线必须换支持异步或并发模型的服务器：Gunicorn（多 worker 进程）+ gevent（协程）组合能较好支撑并发上传；若用异步框架路线，可迁移到 Quart（兼容 Flask 语法的 ASGI 实现），配合 await f.save() 和 asyncio.to_thread() 调用阻塞操作。

Gunicorn 启动时加 --worker-class gevent --workers 4 --worker-connections 1000 可显著提升并发吞吐
别在 Gunicorn worker 里用 threading.Timer 或全局变量存文件状态——worker 进程间不共享内存
上传进度追踪需要前端配合 XHR2 或 fetch + Upload.upload.onprogress，后端仅提供状态接口（如 Redis 存储 session_id → progress）

文件名净化、执行环境隔离、IO 负载卸载——这三个点漏掉任何一个，多文件上传在真实流量下都会出问题。