Python如何实现WebSocket长连接_基于asyncio与websockets库通信-Python教程-PHP中文网

websocket连接建立后立即断开，根本原因是未启动接收循环（如async for或await recv()），导致空闲超时被关闭；必须显式监听消息或发送ping心跳，且所有操作须在同一线程的event loop中await，不可混用线程池。

python如何实现websocket长连接_基于asyncio与websockets库通信

WebSocket连接一建立就断开？检查 `await websocket.recv()` 是否被阻塞

asyncio 下的 WebSocket 长连接本质是靠持续轮询或等待消息维持的，不是“连上就自动活着”。常见现象是客户端连上服务端后几秒内主动断开，抓包看到 1001 Going Away 或服务端抛 ConnectionClosedOK。根本原因往往是没启动接收循环——哪怕你只发不收，也得显式调用 recv() 或 iter 启动协程监听。

必须在连接建立后立即启动一个 async for message in websocket: 或 while True: await websocket.recv() 循环，否则连接会在空闲超时后被底层关闭
如果业务逻辑不需要收消息，也要写个空循环 + await asyncio.sleep(1) 心跳占位，但更推荐发 ping：调用 await websocket.ping() 每 30 秒一次
websockets 默认 ping 超时是 20 秒，若网络延迟高或服务端响应慢，需显式调大：ping_timeout=30 和 ping_interval=25

并发多个 WebSocket 连接时 CPU 占用飙升？别用 `loop.run_in_executor` 包 `websocket.send()`

websockets 的 send() 和 recv() 本身已是协程，内部基于 asyncio.StreamReader/Writer，全程异步无阻塞。有人为“保险”把它丢进线程池执行，结果触发大量线程切换和事件循环争抢，CPU 直接拉满。

所有 websocket.* 方法（send、recv、close、ping）都必须在同一个 asyncio event loop 中直接 await，不能混用线程池
真正需要线程池的是：JSON 序列化大对象、读写本地文件、调用同步第三方 SDK —— 这些才该用 loop.run_in_executor(None, json.dumps, huge_data)
发送高频小消息（如每秒 50 条）时，注意不要在循环里反复 await websocket.send(json.dumps(...))，先批量组装再 send 一次，减少协程调度开销

如何安全地重连？别在 except 里直接 `await websockets.connect()`

捕获 ConnectionClosedError 或 OSError 后立刻重连，容易触发密集重试风暴，把服务端打挂。更糟的是，未清理旧连接资源（比如还在运行的 recv 任务）会导致 socket 句柄泄漏。

提示词大师-python版

图片提示词生成器？不止如此。马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。输入「新手指南」查看完整功能介绍

下载

重连前务必确保旧连接已彻底关闭：调用 await websocket.close() 并等待其完成；若已异常断开，检查 websocket.closed 属性再决定是否调用
加退避策略：首次失败后等 1 秒，第二次 2 秒，第三次 4 秒……上限建议 30 秒，可用 asyncio.sleep(min(30, 2 ** attempt))
用 asyncio.create_task() 启动重连协程，而不是在主逻辑里 await，避免阻塞其他连接的处理
务必设重试上限（比如 5 次），超过后应记录错误并退出，而不是无限循环

为什么用 `websockets` 不用 `aiohttp` 的 WebSocket 支持？看错误码和连接粒度

两者都能做 async WebSocket，但 aiohttp 的 WS 实现绑定在 HTTP session 生命周期里，连接异常时抛出的错误类型模糊（常是泛化的 ClientError），且无法单独控制 ping/pong 行为；而 websockets 是专为 WebSocket 协议设计的库，错误分类细（ConnectionClosedError / ConnectionClosedOK / InvalidState），连接对象生命周期清晰，调试时看到 code=1006 就知道是底层连接异常，code=1008 是协议违规，不用猜。

如果你需要精确控制 close code、自定义 subprotocol、或要求连接对象能独立于 HTTP 请求存在（比如后台常驻连接推送），必须选 websockets
aiohttp 更适合“HTTP 接口带一个临时 WebSocket 升级”的场景，比如单次聊天页面加载后建连，关页即断
注意 websockets 不内置 HTTP 服务，要提供升级接口得自己写 http:// 端点或搭配 starlette/fastapi

事情说清了就结束。最常漏掉的是：忘了在 recv 循环里包 try/except 捕获 ConnectionClosed 类异常，导致整个 task 崩溃后连接静默丢失。