websockets：Python 处理 WebSocket 的首选库

Python 生态里做 WebSocket 的库不少，但 websockets 能拿到 5600+ Star，靠的不是花哨功能。

它专注做一件事：让 Python 开发者用最少的代码搞定 WebSocket 连接。这个定位听起来简单，实际做到却不容易。

上手很简单

websockets 基于 Python 标准库 asyncio 构建。一个 echo 服务端只需要十几行代码：

async def echo(websocket):
    async for message in websocket:
        await websocket.send(message)

async def main():
    async with serve(echo, "localhost", 8765) as server:
        await server.serve_forever()

创建连接用 serve，接收消息用 async for，发送消息用 send。没有回调，没有绕来绕去的配置。

如果你不喜欢异步，它也提供了 threading 版本，用法一样直接：

def hello():
    with connect("ws://localhost:8765") as websocket:
        websocket.send("Hello world!")
        message = websocket.recv()
        print(f"Received: {message}")

两种 API 设计思路一致，切换成本很低。除此之外还有一个 Sans-I/O 实现，给需要完全控制网络层的用户准备。

四个原则

项目 README 直接给出了四个选它的理由，每个都有实打实的支撑。

正确性方面，测试覆盖 100% 分支，严格遵循 RFC 6455 规范。CI 跑不过就合不了代码。

易用性方面，核心 API 就两个操作：收消息和发消息。连接管理全交给库处理，开发者只关心业务逻辑。

健壮性方面，websockets 很早就正确处理了背压问题。在 Python 社区普遍意识到这问题之前，它是当时唯一做到的库。

性能方面，内存使用经过优化且可配置。一个 C 扩展加速了频繁操作，在 Linux、macOS、Windows 上都有预编译的 wheel 包，装完即用。

什么场景用它，什么场景换一个

websockets 定位很明确：只做 WebSocket 协议本身的事。它的 HTTP 支持很弱，只够做健康检查。

如果你需要同时处理 HTTP 和 WebSocket，可以考虑 uvicorn 或 Sanic，它们基于 websockets 往上做了一层封装。

如果你偏好回调风格而不是协程，这个库可能不适合你。它从诞生起就选择了基于协程的 API。

文档和生态

项目文档托管在 Read the Docs，从入门教程到 API 参考都有覆盖。如果用于商业项目，也提供 Tidelift 企业订阅渠道，可以获得商业支持和维护。

对于 Python 开发者来说，websockets 是这个方向上完成度最高的选择。它不追求功能堆砌，而是在 WebSocket 这一个点上做到了足够深入。

，websockets 是这个方向上完成度最高的选择。它不追求功能堆砌，而是在 WebSocket 这一个点上做到了足够深入。