当前位置：首页 > 文章列表 > 文章 > python教程 > PythonWebSocket长连接教程：asyncio与websockets实战

PythonWebSocket长连接教程：asyncio与websockets实战

2026-03-29 14:51:41 0浏览收藏

本文深入剖析了Python中使用websockets库实现稳定WebSocket长连接的关键实践与常见陷阱：强调必须主动启动接收循环（如async for或await recv()）或发送ping心跳来防止空闲超时断连；明确指出所有WebSocket操作必须在同一线程的asyncio事件循环中直接await，严禁混用线程池导致CPU飙升；详解了安全重连的正确姿势——清理旧资源、指数退避、设重试上限及异步任务化；并对比说明websockets相比aiohttp在错误码精准性、连接生命周期控制和协议定制能力上的显著优势，最后点出最易被忽视却致命的问题：未在接收循环中捕获ConnectionClosed异常将导致连接静默失效。

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 句柄泄漏。

重连前务必确保旧连接已彻底关闭：调用 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 崩溃后连接静默丢失。

本篇关于《PythonWebSocket长连接教程：asyncio与websockets实战》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！