asyncio.run()启动慢并非async本身拖沓，而是事件循环初始化、selector注册、信号处理器加载等隐式开销所致，冷启动时占短生命周期脚本总耗时10–30%，可通过复用事件循环或预热协程缓解。
异步程序启动慢，不是因为“async本身拖沓”，而是事件循环初始化和协程调度器预热有开销；多线程靠OS直接分配线程，启动快但后续代价高。
asyncio.run() 初始化事件循环的隐式成本
每次调用 asyncio.run() 都会创建新事件循环、注册信号处理器、初始化 selector（如 epoll 或 SelectSelector），这些操作在冷启动时不可忽略。尤其在短生命周期脚本（如 CLI 工具、一次性爬虫）中，这部分开销可能占总耗时 10–30%。
- 避免反复调用
asyncio.run()：长任务应复用同一循环，用loop.run_until_complete() - Windows 上默认使用
SelectSelector，比 Linux 的EpollSelector启动略慢，可通过环境变量PYTHONASYNCIODEBUG=1观察初始化日志 - 若用 uvloop，首次 import 会触发 C 扩展加载，比纯 Python 的
asyncio多 2–5ms，但后续性能优势远超这点延迟
协程对象创建 vs 线程对象创建的差异
调用 async def 函数返回的是协程对象（coroutine object），它不立即执行，但需解析 AST、绑定闭包、构建帧对象——这比 threading.Thread(target=...) 的轻量封装稍重。
- 协程对象创建开销约 0.1–0.3μs，线程对象约 0.05–0.1μs；单个可忽略，但 1000 个并发协程就多出 ~100μs
- 线程由内核直接管理，Python 层只是包装；协程完全由用户态调度器控制，所有状态（挂起点、局部变量、await 链）都需 Python 对象承载
- 真正影响感知速度的是“首次 await”：第一次
await asyncio.sleep(0)或await aiohttp.get(...)才真正触发事件循环调度逻辑初始化
第三方库的异步客户端预热延迟
像 aiohttp.ClientSession、aiomysql.create_pool 这类对象，在首次 await 前不做连接或 DNS 解析，但内部会做连接池初始化、SSL 上下文预建、缓冲区预分配——这些动作发生在第一次 await，不是定义时。
立即学习“Python免费学习笔记（深入）”；
-
aiohttp.ClientSession()构造函数不耗时，但首次await session.get(...)可能多花 2–8ms（DNS 缓存未命中 + SSL handshake） - 对比
requests.Session()：构造即完成底层连接池 setup，首次请求反而更快 - 解决办法：在主逻辑前加一个 dummy await，比如
await asyncio.sleep(0.001)或await session.get("http://httpbin.org/get", timeout=0.1)预热
启动慢本身不是 bug，而是异步模型为长期高吞吐付出的“入场券”；如果你的程序只跑几秒就退出，多线程确实更干脆；但只要任务持续超过 100ms 或并发数 > 50，异步的调度效率和内存优势就会迅速覆盖启动开销——关键不是“哪个启动快”，而是“在哪种场景下，启动开销值得被换回来”。
