asyncio适合i/o密集且协程可挂起的场景，如aiohttp请求、asyncpg查询、异步文件读写；不适合cpu密集任务如图像处理、数值计算，此时应使用processpoolexecutor。
asyncio 适合什么场景，不适合什么场景
asyncio 不是万能并发解药，它只在 I/O 密集、协程可挂起的场景下真正省资源。CPU 密集任务扔进 asyncio.run() 只会让单线程更忙，还加了调度开销。
常见错误现象：asyncio 跑着跑着 CPU 占满、响应反而变慢；用 time.sleep() 阻塞协程导致整个事件循环卡住。
- 适合：HTTP 请求（
aiohttp）、数据库查询（aiomysql、asyncpg）、文件异步读写（asyncio.open()） - 不适合：图像处理、数值计算、正则反复匹配——这些该交给
concurrent.futures.ProcessPoolExecutor - 注意：
asyncio.to_Thread()是 python 3.9+ 的补救手段，但只是把同步阻塞调用“挪到线程里”，不是原生异步
多线程 vs 多进程：别被 GIL 带偏节奏
GIL 确实存在，但它不等于“Python 不能并发”。关键看瓶颈在哪：如果卡在系统调用（比如 requests.get()），线程就能并行；如果卡在纯 Python 循环，才需要进程。
使用场景差异明显：threading.Thread 启动快、内存共享方便，适合短时 I/O；multiprocessing.Process 开销大、序列化成本高，但能压满多核 CPU。
立即学习“Python免费学习笔记（深入）”；
- 别盲目上
multiprocessing：传参必须可序列化，Lambda、嵌套函数、类实例方法直接报PicklingError -
ThreadPoolExecutor比裸threading更安全，自动管理生命周期，推荐优先用 - windows 下
multiprocessing默认启动方式是spawn，模块级代码可能重复执行——记得包好if __name__ == '__main__':
什么时候该混用（async + thread + process）
真实服务常同时面对 I/O 等待、第三方 SDK 阻塞、本地计算三类负载。硬选一种模型只会让某部分成为瓶颈。
典型组合：asyncio 做主流程编排，把阻塞操作丢给 ThreadPoolExecutor（如调用旧版 requests），再把 CPU 重活交由 ProcessPoolExecutor（如 numpy.linalg.svd）。
- 避免在协程里直接
await loop.run_in_executor(None, ...)：用None表示默认线程池，但没控制权；显式创建ThreadPoolExecutor实例更好管理 - 进程池不能传协程对象，也不能在子进程中调用
asyncio.run()—— 子进程是干净的 Python 解释器，没有父进程的事件循环 - 跨 executor 传递数据尽量轻量：大对象序列化/反序列化比计算本身还慢
调试并发问题比写代码还花时间
竞态、死锁、资源耗尽这些问题不会立刻报错，而是隔几十分钟突然 ConnectionRefusedError 或 RuntimeWarning: coroutine 'xxx' was never awaited。
最容易被忽略的是资源泄漏：忘了关 aiohttp.ClientSession、线程池没 shutdown()、进程池句柄未释放，跑一两天后连接数爆满或文件描述符占尽。
- 用
asyncio.all_tasks()查看还在跑的协程，配合task.get_coro().__name__定位挂起点 -
threading.enumerate()和multiprocessing.active_children()是排查“线程/进程没退出”的基本工具 - 别信日志时间戳：多个线程/协程打日志会交错，加
threading.get_ident()或asyncio.current_task()辅助区分
并发不是加个 async 就完事，它把隐性依赖显性化了——哪段代码依赖全局状态、哪个函数偷偷改了环境变量、谁在共享队列里没取完就 exit，这些细节全得抠清楚。