Flask默认Werkzeug服务器在高并发I/O场景下退化为“假并发”，真正高并发需用gevent协程：monkey.patch_all()必须置于文件首行，Gunicorn须配--worker-class gevent、--worker-connections和--timeout参数，并与数据库连接池合理匹配。
Flask 默认的 Werkzeug 开发服务器在高并发 I/O 场景下会迅速退化为“假并发”——线程数上去了，但实际请求卡在 socket 等待、数据库连接、HTTP 调用上，CPU 空转，QPS 不升反降。真正要撑住几百上千并发，靠堆线程没用，得用 gevent 把阻塞调用切走，让单个 worker 同时跑上千个协程。
为什么默认多线程模式扛不住真实并发
Werkzeug 的多线程模式受 Python GIL 和系统线程开销双重限制：每个线程平均占几 MB 内存，500 并发 ≈ 几 GB 内存；I/O 阻塞时线程挂起，但调度器仍要频繁切换上下文。实测表明，4 核机器上，默认配置 QPS 很难突破 200，错误率随并发增长陡升。
-
flask run本质是单进程同步模型，哪怕开了threaded=True，也只是有限线程池，无事件循环 - 数据库查询、
requests.get()、文件读写等操作一旦未被 patch，就直接阻塞整个线程 - 日志里出现大量
BlockingIOError或 CPU 持续低于 10% 但响应超时，基本就是 I/O 卡死信号
gevent.monkey.patch_all() 必须放在最顶上
这不是可选步骤，而是硬性执行顺序约束。一旦 socket、ssl、urllib 等模块被任意其他 import 触发加载，patch_all() 就失效了——后续所有协程调度退化为同步阻塞。
- 错误写法：
import requests写在monkey.patch_all()前 →requests.get()直接卡死整个 worker - 正确位置：在
app.py第一行（比from flask import Flask还早）写from gevent import monkey; monkey.patch_all() - 验证是否生效：启动日志必须有
Monkey patched字样；压测时观察 CPU 是否长期低于 30% 且 QPS 稳定上升
Gunicorn 启动时漏掉这三项参数，gevent 就等于没开
只加 --worker-class gevent 远远不够。缺一不可：
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
立即学习“Python免费学习笔记（深入）”；
-
--worker-connections 1000：每个 gevent worker 最大并发协程数，默认虽是 1000，但若内存紧张（如 1GB RAM），建议设为256或512，否则 OOM -
--timeout 30：防止某个未 patch 的库卡死协程，拖垮整个 worker；设为业务最长 I/O 耗时的 1.5 倍较稳妥 -
-w $((2*$(nproc)+1))：worker 进程数按 CPU 核心数算，别盲目堆数量——gevent 的设计初衷就是少进程、多协程
哪些代码会让 gevent 静默失效
协程调度只对被 patch 的 I/O 路径有效。以下任一操作出现在请求链路中，都会导致当前 worker 完全阻塞：
- 原生
time.sleep(1)→ 必须换成gevent.sleep(1) - 未 patch 的
subprocess.Popen→gevent.subprocess替代，或移出主请求流 -
threading.Thread或ThreadPoolExecutor→ 协程无法调度线程，整个 worker 锁死 - 用了
Flask-SQLAlchemy但SQLALCHEMY_POOL_SIZE<--worker-connections × --workers→ 所有协程抢不到 DB 连接，全在排队
真正麻烦的不是配置本身，而是 patch 生效边界难以肉眼判断：一个第三方包悄悄 import 了 http.client，就可能让整条链路掉回同步。上线前必须用 --log-level debug + 压测验证，不能只看启动日志有没有 “Monkey patched”。
