Python Web 应用中实现实时通信（WebSocket），经常会遇到一个架构矛盾：基于同步 WSGI 标准设计的 Flask 框架，遵循「请求→线程处理→返回响应」的简单流程；而 WebSocket 则需要持久化、有状态的长连接，连接可能保持数小时。传统同步模型根本无法支撑。为了打通 Flask 同步特性与 WebSocket 异步需求的问题，Flask-SocketIO 依赖Greenlet（微线程） 实现并发，核心支撑库正是Eventlet和Gevent。这两个库能让标准 Flask 应用，在单个操作系统线程中处理数千个并发连接。让我们先看看为什么传统线程无法支持高并发WebSocket？在Gunicorn同步/线程工作模式等传统WSGI部署中，并发数=操作系统线程/进程数。1:1绑定的模式会有两个致命瓶颈：一是内存开销爆炸，二是上下文切换延迟。加上Python GIL限制，同一时间只能有一个线程执行Python字节码，即便是I/O操作会释放GIL，数千个线程的管理开销仍然无法接受。Eventlet 和 Gevent 通过greenlet C 扩展库实现协程（用户态协作式线程），完全在用户空间管理，不需要内核参与，完美解决了上述问题。CPython解释器使用标准C栈执行函数调用，要让函数在I/O阻塞时暂停，必须保存栈状态。所有的微线程共享同一个操作系统线程和内存空间；上下文切换仅需内存拷贝，耗时从微秒级降到纳秒级；微线程初始栈仅几KB，单机成可承载数万个并发。
Python 标准库（socket、time 等）都是阻塞式的，在单线程的 Eventlet/Gevent 中，一个阻塞调用会卡死整个服务。Monkey Patch则是解决这个问题的，执行eventlet.monkey_patch()或gevent.monkey.patch_all()时，库会动态修改 Python 标准库，对于开发者来说，代码写法还是同步写法，但是底层已经是异步非阻塞执行。
使用Flask-SocketIO必须配置async_mode，三种方案对比如下：
1. Threading（标准线程）• 并发模型：操作系统原生线程• 优点：兼容性拉满，无需打补丁，适配所有第三方库• 缺点：扩展性极差，仅支持数百连接• 适用场景：开发调试、低流量内部工具2. Eventlet• 并发模型：Greenlet 微线程• 现状：已废弃，仅维护，停止新功能开发，Python3.10 + 兼容性差• 性能：高，但吞吐量略低于 Gevent• 适用场景：遗留老项目，新项目禁止使用3. Gevent（生产首选）• 并发模型：Greenlet 微线程• 架构：基于高性能 C 库libev+Cython 开发• 现状：活跃维护，稳定可靠• 性能：极高，低延迟、低资源占用• 适用场景：所有新生产环境
通过5000并发Websocket链接进行测试对比
Threading 直接崩溃或者无响应
Eventlet CPU占用非常高
Gevent CPU和内存占用低，轻松承载。
使用Gevent简单配置示例：
# standard_library_patch.py# 第一步：必须在导入任何库之前打补丁！from gevent import monkeymonkey.patch_all()from flask import Flaskfrom flask_socketio import SocketIO, emit# 初始化Flaskapp = Flask(__name__)app.config['SECRET_KEY'] = 'your-secret-key'# 初始化SocketIO，指定gevent模式socketio = SocketIO( app, async_mode='gevent', # 水平扩容必需：Redis消息队列 message_queue='redis://localhost:6379')# 客户端连接事件@socketio.on('connect')def handle_connect(): print('客户端已连接')# 接收消息事件@socketio.on('message')def handle_message(data): print('收到消息：', data) emit('response', {'data': '消息已收到'})# 本地运行if __name__ == '__main__': socketio.run(app, host='0.0.0.0', port=5000)
不要用python app.py运行，使用gevent工作类启动：
gunicorn -k gevent -w 1 module:app
总之，要想深入理解，不妨亲自动手来尝试。
10个月宝宝每天需要喝多少奶粉？
