Python并发核心在于理解执行模型：线程适用于IO密集型任务，协程用于高并发单线程调度，进程解决CPU密集型并行；GIL限制多线程并行但不阻碍IO并发，asyncio需避免阻塞调用，选型应依场景而定。
Python并发系统的核心不在语法，而在对执行模型的理解——线程、协程、进程三者不是并列选项，而是针对不同IO特征和资源约束的分层解法。
理解GIL：它不阻止并发，但限制并行
CPython解释器中的全局解释器锁（GIL）只允许同一时刻一个线程执行Python字节码。这意味着：
- CPU密集型任务用多线程无法提速，反而因线程切换增加开销
- IO密集型任务中，线程在等待网络/磁盘时会主动释放GIL，其他线程得以运行，因此多线程仍能提升吞吐
- 若需真正并行计算，应使用multiprocessing（绕过GIL）或C扩展（如NumPy内部已规避GIL）
asyncio不是“更快的线程”，而是单线程内的协作式调度
async/await关键字本身不带来性能，关键在于事件循环如何统一管理挂起与恢复：
- await后必须是可等待对象（Awaitable），如协程、Task、Future，普通函数或time.sleep()不能直接await
- 阻塞调用（如requests.get、sqlite3.execute）会卡住整个事件循环，必须改用异步等价物（aiohttp、aiosqlite）或用loop.run_in_executor委托给线程池
- asyncio.create_task()立即调度协程，而直接调用协程函数只返回协程对象，不会自动执行
合理选型：从场景反推并发模型
不必追求“最先进”，而要看实际瓶颈在哪里：
立即学习“Python免费学习笔记（深入）”；
- 高并发HTTP客户端（如爬虫、API聚合）→ asyncio + aiohttp（连接复用+无锁调度）
- 混合负载服务（部分同步DB操作+部分实时推送）→ trio 或 curio（更严格的取消语义）或 asyncio + 线程池/进程池混用
- 数据清洗+机器学习预处理 → multiprocessing.Pool 或 concurrent.futures.ProcessPoolExecutor（CPU绑定任务）
- 轻量级后台任务（如日志轮转、缓存刷新）→ threading.Thread 或 asyncio.to_thread（Python 3.9+）
实战避坑：几个真实易错点
写并发代码时，逻辑正确≠行为可靠：
- 共享状态未加锁：threading.Lock 或 asyncio.Lock 不是装饰器，需显式 acquire/release 或用 async with
- 忘记await：常见于调用协程却没await，导致返回coroutine object而非结果，后续报错位置远离问题源头
- 异常未传播：asyncio.gather(..., return_exceptions=True) 可捕获子任务异常，否则第一个异常就中断全部
- 资源泄漏：异步上下文管理器（async with）和异步迭代器（async for）必须成对出现，否则文件句柄、连接可能不释放
