uvloop在IO密集型场景下通常提升1.3–1.8倍吞吐量，非万能加速器；它通过Cython重写epoll/kqueue逻辑减少调度开销，但对CPU密集型任务无效，且仅支持Linux/macOS。
uvloop真能翻倍吞吐量？先看实际效果边界
不能一概而论。uvloop在IO密集型场景（如HTTP短连接、Redis批量读写）下，通常比默认asyncio事件循环快1.3–1.8倍；但若任务含大量CPU计算、或频繁调用asyncio.to_thread()、loop.run_in_executor()，提升会迅速衰减甚至归零。关键不是“翻倍”，而是减少事件循环调度开销和系统调用次数——uvloop用Cython重写了底层epoll/kqueue逻辑，避免了CPython asyncio中Python层的冗余对象分配和回调包装。
实操前务必确认：
- 运行环境是Linux/macOS（Windows不支持uvloop）
- Python ≥ 3.8（uvloop ≥ 0.17要求）
- 没有手动调用asyncio.set_event_loop_policy()覆盖过策略
- 项目未依赖某些硬绑定默认循环的库（如旧版aiohttp 3.7-在测试工具中可能出问题）
三行代码启用uvloop，但顺序不能错
必须在任何asyncio模块被导入之前就安装uvloop，否则无效。常见错误是先写了import asyncio再调uvloop.install()——此时asyncio已构建好默认循环，install只是“挂了个空钩子”。
正确做法：
import uvloop
uvloop.install()
<p>import asyncio</p><p><span>立即学习</span>“<a href="https://pan.quark.cn/s/00968c3c2c15" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">Python免费学习笔记（深入）</a>”；</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/skill11354" title="Python Pep Authoring"><img
src="https://img.php.cn/upload/skill/001/246/273/6adaf20e695c2374.jpg" alt="Python Pep Authoring" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/skill11354" title="Python Pep Authoring">Python Pep Authoring</a>
<p>依据官方 python/peps仓库规则起草、审阅、编辑或准备 Python 改进提案（PEP），用于处理 PEP 文本和元数据头部。</p>
</div>
<a href="/xiazai/skill11354" title="Python Pep Authoring" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div><h1>后续所有 asyncio.create_task() / asyncio.run() 都自动使用 uvloop</h1><p>如果你用asyncio.run(main())启动，这三行足够；但若用asyncio.get_event_loop()或自定义EventLoopPolicy，需额外注意：
- 不要再调用asyncio.set_event_loop_policy()
- 避免在子进程中重复install（uvloop不支持fork后复用）
- 若用pytest-aiohttp等测试框架，需在conftest.py顶部提前install，而非测试函数内
为什么压测时吞吐没变化？检查这四个盲点
典型假阴性原因：
- 瓶颈不在事件循环：比如数据库连接池只有5个连接，uvloop再快也卡在
await pool.acquire() - 用了
time.sleep()代替await asyncio.sleep()：前者阻塞整个线程，uvloop完全无法调度 - HTTP客户端没关keepalive：
aiohttp.ClientSession(connector=TCPConnector(limit=100))比默认的100连接更关键 - 日志打太猛：
logging.info()在高并发下本身是同步IO，建议用aiologger或异步handler
快速验证uvloop是否生效：print(asyncio.get_event_loop().__class__.__name__) —— 应输出uvloop.Loop，而非asyncio.events._UnixSelectorEventLoop
uvloop + 协程模式下的真实性能取舍
uvloop加速的是“等待就绪”和“分发回调”的过程，不是协程本身。这意味着：
- 单个协程里做
sum(range(10**7))，uvloop毫无帮助；应改用asyncio.to_thread()或concurrent.futures.ProcessPoolExecutor - 大量
async for迭代异步生成器时，uvloop对迭代器创建开销无优化，重点应放在减少yield次数或批处理 - uvloop的
run_until_complete()比标准循环略快，但asyncio.run()封装层差异可忽略——别为这点微差改启动方式
最常被忽略的一点：uvloop默认禁用信号处理（如SIGINT），若你的服务需要优雅退出，得手动补上loop.add_signal_handler(signal.SIGINT, ...)，否则Ctrl+C可能直接kill进程而不await cleanup。
