Flask 默认开发服务器无法应对并发，必须替换为 Gunicorn + gevent 组合：Gunicorn 管理多进程，gevent 通过 monkey patch 实现协程调度，但需确保 patch 在所有模块导入前执行、正确配置 worker-connections、并将 CPU 密集型任务移至 ProcessPoolExecutor。
Flask 默认的 flask run 服务器完全不能扛并发，5个并发请求就卡死，QPS 掉到 0.3 以下——这不是代码写得差，是 Werkzeug 开发服务器压根没设计成生产用。真正能提升并发能力的，只有换掉它，并正确启用 gevent 协程模式。
为什么 Gunicorn + gevent 是当前最稳妥的组合
Gunicorn 提供多进程管理，gevent 提供单线程内高并发调度，两者叠加能同时解决 CPU 多核利用和 I/O 阻塞问题。相比 eventlet，gevent 社区更活跃、patch 行为更稳定，尤其对 SSL、requests、数据库驱动等关键模块兼容性更好。
但注意：gevent 不是“开箱即用”，它依赖 monkey patch —— 必须在任何标准库模块（如 socket、ssl、threading）被导入前完成 patch，否则协程会静默退化为同步行为。
-
gevent.monkey.patch_all()必须放在app.py最顶部，早于from flask import Flask、import requests、from flask_sqlalchemy import SQLAlchemy - 如果用了
requests，确认已安装gevent-requests或确保patch_all(ssl=True)被调用，否则 HTTPS 请求会阻塞整个协程栈 - Gunicorn 启动后立即退出且无报错？大概率是 patch 前就触发了模块导入（比如 SQLAlchemy 在 patch 前就初始化了连接池）
启动命令与关键参数含义
正确启动命令长这样：
立即学习“Python免费学习笔记（深入）”；
gunicorn -w 4 -k gevent --worker-connections 1000 -b 0.0.0.0:5000 --timeout 120 app:app
其中：
-
-w 4：启动 4 个 worker 进程，建议设为 CPU 核心数 × 1~2（不是越多越好，进程间切换有开销） -
-k gevent：指定使用 gevent worker 类，这是启用协程的关键开关 -
--worker-connections 1000：每个 gevent worker 最多处理 1000 个并发连接（协程），这个值必须配合patch_all()才生效 -
--timeout 120：避免长时间推理或 OCR 处理被误杀，尤其对 AI 类服务很关键
漏掉 --worker-connections，gevent 就只是个“带点异步味儿的普通 worker”，并发能力几乎不涨。
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
OCR/模型推理类服务要额外防住 CPU 阻塞
gevent 只能调度 I/O 等待，对纯 CPU 计算（如 OpenCV 预处理、CRNN 推理）完全无效——一个协程跑满 CPU，其他协程就全卡住。
实操上必须拆解：
- 把耗时 >100ms 的图像预处理、模型推理逻辑从主线程移出，改用
concurrent.futures.ProcessPoolExecutor执行（注意：不能用 ThreadPoolExecutor，GIL 下无效） - 视图函数里只做轻量操作：接收请求 → 提交任务 → 返回响应（可含 task_id），后续用轮询或 WebSocket 推送结果
- 别在 gevent worker 里直接调
model.predict()，那等于给所有协程下毒
否则你会看到：QPS 上去了一点，但平均延迟反而飙升，且部分请求超时——这是典型的 CPU 密集型任务挤占协程调度的表现。
容易被忽略的 patch 时机和日志验证点
很多人写了 patch_all() 还是没效果，是因为它被放在了错误位置。最保险的写法是：
from gevent import monkey<br>monkey.patch_all(ssl=True, threading=True, socket=True)<br><br>from flask import Flask<br># 其他 import 全放在这里之后
验证是否生效的最快方式：在视图函数里加一行 import gevent; print(gevent.getcurrent())，并发请求下应看到大量不同 Greenlet 对象 ID；如果全是同一个，说明 patch 失败或根本没走 gevent worker。
真正的瓶颈从来不在配置行数，而在于 patch 是否真生效、CPU 任务是否真剥离、SSL 和数据库驱动是否真被协程接管——这三个点任何一个没踩准，gevent 就只是个昂贵的装饰品。
