asyncio高并发更省资源因规避GIL限制与线程开销：单线程协程让出控制权，1000请求仅需一个事件循环，内存稳定；而多线程易触系统线程上限，且需复用ClientSession、避免阻塞调用。
为什么 asyncio 在高并发下比多线程更省资源
因为 Python 的 GIL 让多线程无法真正并行 CPU 密集任务，而异步 IO 的核心是「单线程内让出控制权」，避免了线程创建、上下文切换和锁竞争的开销。1000 个并发 HTTP 请求，用 threading 可能要起近千个线程，内存占用飙升；用 asyncio + aiohttp，通常只需一个事件循环加少量协程栈，内存稳定在几十 MB。
关键不是“更快”，而是“更稳”：连接数上去后，线程模型容易触发系统级限制（如 Linux 的 /proc/sys/kernel/threads-max），而 asyncio 只受限于文件描述符数量（可通过 ulimit -n 调整）。
asyncio.run() 和 asyncio.create_task() 别混用
新手常把所有协程都塞进 asyncio.run()，结果每次调用都新建事件循环，无法复用连接池、无法共享状态。真实服务中（比如 FastAPI 或自建 TCP server），应该只在入口调用一次 asyncio.run()，其余逻辑用 asyncio.create_task() 或 asyncio.gather() 管理并发。
-
asyncio.run(main())：仅用于脚本启动，不能嵌套调用 -
asyncio.create_task(coro)：在已有事件循环中启新协程，适合长周期后台任务（如心跳、日志上报） -
await asyncio.gather(*coros)：适合批量发起 IO 并等待全部完成，但要注意异常传播——任一协程抛错，整个gather就中断
aiohttp.ClientSession 必须复用，不能每个请求都 new 一个
每次 new aiohttp.ClientSession() 都会重建连接池、SSL 上下文和 cookie jar，不仅慢，还会快速耗尽本地端口（TIME_WAIT 状态堆积）。正确做法是全局单例或依赖注入：
立即学习“Python免费学习笔记（深入）”；
session = aiohttp.ClientSession()
try:
async with session.get("https://api.example.com") as resp:
...
finally:
await session.close() # 注意：必须显式 close，否则连接不释放
如果用在 Web 框架里（如 Starlette），推荐用 lifespan hook 或中间件管理生命周期；若只是短脚本，可用 async with aiohttp.ClientSession() as session: 确保自动清理。
阻塞操作会拖垮整个 event loop
任何同步阻塞调用（比如 time.sleep()、requests.get()、JSON 解析大文件、正则匹配超长文本）都会让整个事件循环卡住，所有协程暂停——这比多线程还糟，因为没备用线程兜底。
解决方式只有两个：
- 用异步替代品：用
asyncio.sleep()替代time.sleep()，用aiofiles替代open()，用ujson（纯 C）而非json（Python 实现）加速解析 - 把阻塞操作扔到线程池：
await asyncio.to_thread(blocking_func, *args)（Python 3.9+），或老版本用loop.run_in_executor()
最容易被忽略的是日志：默认 logging 是同步写文件的，高并发下可能成瓶颈，建议用 aiologger 或配置异步 handler。
