直接用 websockets 库可实现异步 websocket 通信，但需重点处理协程生命周期、连接管理与错误恢复；async for 不会阻塞事件循环，但客户端断开未触发异常、大消息未分片或混用同步 i/o 时会卡住；广播应并发发送并独立捕获异常；uvloop 和 httptools 能显著提升压测性能；心跳与 finally 清理是保障连接集合干净的关键。
直接用 websockets 库就能跑通异步 WebSocket 通信，不需要额外框架包装。关键不是“能不能做”，而是协程生命周期、连接管理、错误恢复这三处容易崩。
async for message in websocket 会卡住吗？
会，但只在特定条件下：客户端断开时未触发异常、消息体过大未分片、或 websocket.recv() 被手动替换成阻塞调用。标准 async for 是基于底层 recv() 的协程封装，本身不会阻塞事件循环。
- 确保没在循环里混用同步 I/O（比如
time.sleep()、requests.get()） - 大消息（>1MB）建议启用
max_size=None或提前分帧，否则可能因缓冲区满而挂起 - 若需超时控制，用
asyncio.wait_for(websocket.recv(), timeout=5)，别依赖async for自带超时
如何安全地广播消息给所有在线客户端？
不能直接遍历集合并发 await websocket.send()——某个连接已断开时会抛出 websockets.exceptions.ConnectionClosed，中断整个广播流程。
- 用
asyncio.create_task()并发发送，每个任务独立捕获异常 - 维护连接集合时，必须在
try/except/finally中增删：连接建立时add()，异常或关闭时remove() - 避免用
list(connected)快照式遍历，集合可能在迭代中途被修改；改用connected.copy()
uvloop 和 httptools 真的有必要加吗？
对开发调试无感，但压测时差别明显：1000+ 并发下，纯 asyncio 默认事件循环吞吐量约 3200 msg/s，加 uvloop 后可达 8900+，httptools 则让握手延迟从 ~12ms 降到 ~4ms。
-
uvloop替换只需两行：import uvloop; asyncio.set_event_loop_policy(uvloop.EventLoopPolicy()) -
httptools是可选依赖，websockets会自动检测并使用它，无需代码改动 - Windows 上
uvloop支持有限，CI/CD 流水线建议加平台判断
客户端断连后，服务端怎么及时清理资源？
靠 except websockets.exceptions.ConnectionClosed 捕获不够——网络闪断、Nginx 代理超时、防火墙 Kill 连接等场景下，异常可能延迟数秒甚至不触发。
- 必须配心跳：服务端用
ping_interval=20（秒），客户端对应设pong_timeout=10 - 在
handler协程末尾加finally块，强制从连接集合移除当前websocket - 不要依赖
websocket.close_code判断是否“正常关闭”，很多断连根本走不到 close 阶段
真正难的不是写通第一条消息，而是当 500 个客户端同时重连、其中 3 台机器网络抖动、Nginx 把 Upgrade 头吃掉一半时，你的 connected 集合还干不干净，心跳有没有漏发，日志能不能准确定位到哪条连接卡在 recv 上——这些细节不压测根本看不出来。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
