asyncio仅适用于i/o密集型任务，cpu密集型需用进程池或c扩展；避免同步阻塞调用、重复创建session、滥用asyncio.sleep；注意异步生成器异常传播与连接池复用。
asyncio 不是万能的，它只对 I/O 密集型任务有效
如果你的代码里有大量 time.sleep()、numpy.dot() 或正则反复匹配大文本，加 async 只会让性能更差——Python 的 GIL 不会让 CPU 密集型操作并发执行，反而增加协程调度开销。
典型误用场景：async def process_data(): 里面直接调用 pandas.read_csv() 或 cv2.imread()。这些函数本身是同步阻塞的，不会让出控制权，整个 event loop 就卡住了。
- 判断标准：该操作是否在等网络响应、磁盘读写、数据库返回？是 → 适合 async；否 → 考虑多进程或 C 扩展
- 替代方案：CPU 密集型任务必须用
loop.run_in_executor()丢给线程池/进程池，不能直接 await - 常见坑：
asyncio.to_thread()（Python 3.9+）比手动建ThreadPoolExecutor更简洁，但别在循环里反复创建 executor
别用 asyncio.sleep() 模拟真实延迟，它会阻塞整个协程栈
asyncio.sleep() 是协作式暂停，没问题；但很多人把它当成“异步版 time.sleep()”滥用，比如在重试逻辑里写 await asyncio.sleep(1) 后立刻发请求——这本身没错，错在没意识到：如果上游调用链没用 await，sleep 就根本不会生效。
更隐蔽的问题是“伪并发”：100 个任务都 await 同一个 asyncio.sleep(1)，它们确实同时启动，但也会同时醒来，瞬间打爆下游服务。
- 真实 I/O 延迟应由实际调用触发（如
httpx.AsyncClient.get()），不是靠 sleep 挤时间窗 - 需要错峰时，用
random.uniform(0.1, 0.5)加到 sleep 时间里，避免雪崩 - 绝对不要在
__aenter__/__aexit__里写长 sleep，会导致 async context manager 阻塞资源释放
连接池和 session 复用是 async HTTP 性能的关键瓶颈
每次发请求都新建 httpx.AsyncClient() 或 aiohttp.ClientSession()，等于每轮都重建 TCP 连接、TLS 握手、DNS 查询——这比同步请求还慢。async 的优势全被浪费在连接开销上。
错误示范：async def fetch(url): async with httpx.AsyncClient() as client: return await client.get(url)。这个函数每调用一次就新建 session，1000 次调用 ≈ 1000 次握手。
- 正确做法：全局单例复用
httpx.AsyncClient()，或用 contextvars 绑定 per-request session（需配合 lifespan 管理） - 注意
limits参数：httpx.Limits(max_connections=100)控制并发连接数，不设会默认 10，成为隐性瓶颈 - aiohttp 的
connector必须显式传入TCPConnector(limit_per_host=30)，否则默认按 host 限流为 100，但实际可能更早触发系统文件描述符限制
async for 和异步生成器容易漏掉异常传播
用 async for item in async_iterable: 时，如果迭代器内部抛出异常（比如网络中断、JSON 解析失败），这个异常可能被吞掉，或者只在 __anext__() 调用时才暴露，导致 debug 困难。
尤其在流式处理 API 响应（如 Server-Sent Events、分块 JSON）时，async for 看似简洁，但错误位置和堆栈常指向 event loop 内部，而非你写的业务逻辑。
- 务必在 async generator 函数内用 try/except 包裹 yield 前的 I/O 操作，并 re-raise 或记录上下文
- 避免在
async for循环体里做耗时解析，否则会拖慢整个迭代节奏；先await拿到 chunk，再同步解析 - 调试技巧：临时把 async generator 改成普通 generator +
asyncio.create_task()分发，更容易定位哪次 yield 出问题
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
