gevent未生效的主因是monkey.patch_all()未置于所有import之前，导致socket、ssl等模块未被协程化，使协程静默退化为同步；必须将其放在app.py首行，并配合--worker-connections等参数正确配置。
加了 --worker-class gevent 但并发没提升，基本可以断定 gevent 没真正生效——最常踩的坑是 monkey.patch_all() 没放对位置，或被提前导入的模块绕过了 patch。
monkey.patch_all() 必须放在所有 import 之前
gevent 的协程调度依赖 patch 标准库（socket、ssl、threading、select 等），漏一个就可能让整个协程挂起。一旦某个模块（比如 requests、psycopg2、Flask-SQLAlchemy）在 patch 前完成初始化，它内部用的还是原生阻塞 IO。
-
monkey.patch_all()必须写在入口文件（如app.py）的第 1 行，早于from flask import Flask、import requests、from sqlalchemy import create_engine等任何可能触发 IO 的导入 - 如果用了
Flask-SQLAlchemy，确保SQLALCHEMY_POOL_SIZE≥--worker-connections×--workers，否则连接池争抢会导致请求排队 - 启动时加
--log-level debug，看日志里有没有Booting worker with pid: XXX和using gevent字样；若只看到sync，说明 worker class 没生效
--worker-connections 不设等于白配 gevent
--worker-connections 是 gevent worker 的核心参数，它定义每个 worker 最多能并发处理多少个协程。不显式指定时，gunicorn 会用默认值 1000，但这个值只有在 monkey.patch_all() 成功后才真正生效——否则 gevent 退化为同步模型，--worker-connections 形同虚设。
- 内存紧张（如 1GB RAM）时，建议设为
256或512，避免 OOM - 搭配
--workers 4时，总理论并发数 =4 × --worker-connections，但实际受数据库连接池、外部 API 限流等制约 - 压测中若 CPU 很低但大量请求超时，大概率是 patch 失败或未 patch 的库（如某些 C 扩展）导致协程卡死
哪些代码会让 gevent 静默失效
gevent 只能调度被 patch 过的 IO 操作。以下代码一旦出现在请求路径中，就会让当前 worker 完全阻塞，失去并发能力：
- 未 patch 的
requests.get()：确认monkey.patch_all(ssl=True)已执行，或改用gevent-requests - 直接调用
subprocess.Popen()：它不走 socket，patch 不到；应换gevent.subprocess或移至ProcessPoolExecutor - 使用
threading.Thread或concurrent.futures.ThreadPoolExecutor：协程无法调度线程，整个 worker 被锁住 - CPU 密集型任务（如 OpenCV 图像预处理、模型推理）：gevent 对纯计算无感，必须剥离到
ProcessPoolExecutor中运行
启动命令里不能省的三项参数
只写 gunicorn -w 4 -k gevent app:app 是危险的，默认配置容易掩盖问题：
-
--worker-connections 1000：必须显式指定，否则 gevent 并发能力几乎不涨 -
--timeout 30：防止协程卡死拖垮整个 worker；低于 10 秒易误杀正常长请求，高于 60 秒难暴露阻塞点 -
--log-level info：启动时能看到实际加载的 worker 数、connections 数、使用的 class，避免“以为起了 4 个 gevent，其实只起了 1 个 sync”
真正跑起来的最小安全命令类似：gunicorn -w 4 -k gevent --worker-connections 512 --timeout 30 --log-level info -b 0.0.0.0:5000 app:app。复杂点在于 patch 时机和第三方库兼容性——它们不会报错，只会悄悄退化成单线程。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
