uvloop 替换 asyncio 默认事件循环仅在事件循环调度密集型场景（如高并发长连接、大量短 HTTP 请求）下提升10%–40%吞吐，对 CPU 密集或同步阻塞操作无效；需正确安装 libuv、避免混用同步调用，并确保全链路异步。
uvloop 替换 asyncio 默认事件循环是否真能提效
多数情况下不能直接提效，尤其当业务逻辑本身是 CPU 密集型、或 I/O 瓶颈不在事件循环层时。uvloop 加速的是事件循环调度开销（比如成千上万个 asyncio.sleep() 或空闲连接的轮询），不是你的数据库查询或 JSON 解析。
典型受益场景：高并发长连接服务（如 WebSocket 网关、实时消息推送）、大量短生命周期 HTTP 客户端请求（aiohttp / httpx 并发调用）。
- 实测差异常在 10%–40% 吞吐提升，但前提是压测工具没成为瓶颈，且服务端不卡在锁、GIL 或慢 SQL 上
- 替换后
asyncio.get_event_loop()返回的仍是uvloop.Loop实例，大部分现有代码无需改动 - 注意：Python 3.12+ 中
asyncio.set_event_loop_policy()已被弃用，应改用asyncio.run(..., loop_factory=uvloop.new_event_loop)
uvloop 在 Docker 容器里启动失败的常见原因
最常遇到的是 ImportError: libuv.so.1: cannot open shared object file 或进程直接 segfault —— 这基本等于 uvloop 没正确编译或运行时找不到 libuv。
- Docker 基础镜像选
python:3.11-slim时，必须手动装libuv1（Debian/Ubuntu）或libuv（Alpine），仅pip install uvloop不够 - Alpine 镜像需用
apk add --no-cache libuv，且确保uvloop是从源码编译安装（pip install --no-binary uvloop uvloop），否则预编译 wheel 可能不兼容 - 若用多阶段构建，注意
uvloop必须在最终运行镜像中重新安装，不能只复制site-packages
uvloop 和 sync 调用混用时的隐藏阻塞点
uvloop 不改变 Python 的 GIL 行为，也不让同步函数变异步。一旦你在协程里调了 time.sleep()、requests.get() 或任何未做异步封装的阻塞操作，整个事件循环就卡住 —— 此时 uvloop 再快也没用。
立即学习“Python免费学习笔记（深入）”；
- 别依赖
asyncio.to_thread()或loop.run_in_executor()来“打补丁”，它们只是把阻塞挪到线程池，增加上下文切换开销 - 真实 IO（HTTP、DB、文件读写）务必用对应异步库：
httpx.AsyncClient、asyncpg、aiofiles -
uvloop对asyncio.subprocess支持良好，但若子进程本身输出量大或未及时读 stdout/stderr，仍会因管道缓冲区满而阻塞
PyPI 上 uvloop wheel 兼容性陷阱
官方 PyPI 的 uvloop wheel 仅提供 Linux x86_64 + macOS ARM64/x86_64 的预编译版本，其他平台（ARM32、Windows WSL2 的某些内核、musl 系统）默认 fallback 到源码编译 —— 这要求构建环境装好 libuv 开发头文件和 C 编译链。
- CI/CD 流水线里 pip install uvloop 失败？先检查
gcc、pkg-config和libuv1-dev（Debian）或libuv-devel（CentOS）是否就位 - Windows 下
uvloop仅支持原生 Windows（非 WSL），且 Python 必须 ≥ 3.8；WSL2 用户建议直接用标准asyncio，避免无谓折腾 - 生产部署前务必验证
import uvloop; uvloop.install()是否静默成功，而不是只看 pip install 输出
真正难的从来不是换上 uvloop，而是确认你的整个异步调用链——从 HTTP 客户端、数据库驱动、到日志写入——没有一处偷偷掉回同步世界。
