flask原生不支持websocket，因wsgi协议未定义upgrade处理机制；只有flask-socketio能完整集成session、g、钩子及上下文生命周期，通过重建通信模型实现与flask深度对齐。
Flask 本身不支持原生 WebSocket，硬上 request.environ.get("wsgi.websocket") 只在极少数 WSGI 服务器（比如 gevent-websocket）下偶然能跑，一换 gunicorn 或加 nginx 就直接 502 或连接重置——这不是配置问题，是架构不兼容。
你真正需要的不是“能不能连上”，而是“连上了之后还能用 Flask 的 session、g、蓝图路由、上下文生命周期吗？”答案很明确：只有 Flask-SocketIO 能做到。
为什么原生 WS 在 Flask 里根本走不通
WSGI 协议本身不定义 WebSocket 升级流程，Flask 作为 WSGI 框架，压根没预留处理 Upgrade: websocket 请求头的机制。所谓“原生”方案，本质是绕过 Flask 路由和中间件，直接从 environ 里抠出底层 socket，结果就是：
-
request对象不完整，session为空或失效 - 无法使用
@app.before_request、@app.teardown_appcontext等钩子 - 跨域时 Cookie 不自动携带，且无统一 CORS 控制点
-
url_for()、current_app、g全部不可用
Flask-SocketIO 怎么解决这些断层
它不是简单封装 WebSocket，而是重建了一套与 Flask 生命周期对齐的通信模型：
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 连接建立时自动触发
@socketio.on('connect')，此时request和session已就位（前提是初始化时传manage_session=True） - 所有事件处理器（如
@socketio.on('message')）运行在完整的 Flask 应用上下文中，可直接读写session、查数据库、调用url_for() - 前端用
io()连接时，只要配{ withCredentials: true }，Cookie 就能透传；后端配cors_allowed_origins即可控制来源 - 广播时用
broadcast=True，排除自己用include_self=False，不用手动维护连接池
eventlet / gevent 不装会怎样
Flask-SocketIO 启动时若没装异步后端，会直接报错：RuntimeError: You need to use the eventlet server。这不是警告，是启动失败。
- 开发阶段推荐
pip install eventlet，然后初始化时显式指定async_mode="eventlet" - 别用
async_mode="threading"上生产——它只是线程模拟，并发超过 10 个连接就卡死或丢包 -
nginx部署时必须透传两个头：Upgrade和Connection，否则升级失败，降级成 polling 也无效
Session 共享最容易踩的三个坑
很多人以为开了 manage_session=True 就万事大吉，其实关键细节藏在连接建立后的第一帧里：
-
@socketio.on('connect')里session可能还没加载完成，建议改用@socketio.on('auth')手动传 token 解析 - 前端必须带凭证：
io({ withCredentials: true })，否则 Cookie 不发；跨域时后端还要设cors_allowed_origins=["https://your-frontend.com"] -
request.sid是连接 ID，不是用户 ID——同一用户开两个标签页，会拿到两个 sid，绑定用户得靠自己查库或存映射字典
Flask-SocketIO 把这件事做完了，其它方案只是给你开了个口子，剩下的全得你自己填。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
