Python阻塞I/O会使线程空等，降低CPU利用率与响应速度；虽释放GIL但无法真正并行，需用asyncio、多进程、超时控制或线程池缓解。
Python 的 I/O 阻塞会直接让当前线程停在读写操作上，直到数据就绪或传输完成，期间 CPU 无法执行其他任务——这在高并发、低延迟或大量文件/网络操作场景下，会显著拖慢整体性能。
阻塞式 I/O 拖慢单线程程序
默认的 open()、socket.recv()、input() 等都是阻塞调用。例如读一个远程 API 或大文件时，线程会空等，CPU 利用率低但响应变慢。
- 一次 HTTP 请求耗时 500ms，10 个串行请求就要 5 秒；换成并发可压到接近 500ms
- 读取本地大文件时若磁盘忙，
f.read()可能卡住几十毫秒，影响实时性要求高的逻辑
阻塞加剧 GIL 下的并发瓶颈
CPython 中，I/O 阻塞虽会释放 GIL，但线程仍被系统挂起，无法切换到其他 Python 工作线程——也就是说，多线程并不能真正“并行处理 I/O”。
- 用
threading启 10 个线程做 HTTP 请求，实际仍是轮流等待，吞吐未必提升 - 真正的并发收益需配合非阻塞 I/O（如
select、epoll）或异步模型（asyncio）
常见缓解方式与适用场景
不依赖外部库的前提下，有几种实用路径：
立即学习“Python免费学习笔记（深入）”；
-
用
asyncio+aiohttp/aiosqlite：适合 I/O 密集型服务（如 Web 后端），单线程高效复用连接 -
多进程（
multiprocessing）：绕过 GIL，适合 CPU + I/O 混合任务（如批量处理文件+计算） -
设置超时 + 异常捕获：避免无限等待，如
socket.settimeout(3)或urlopen(..., timeout=5) -
使用线程池（
concurrent.futures.ThreadPoolExecutor）：对已有阻塞函数做轻量封装，比裸写线程更安全可控
一个小对比：阻塞 vs 非阻塞读文件
以下不是性能最优解，但能说明差异：
- 阻塞方式：
with open('huge.log') as f: data = f.read()—— 调用返回前什么都不能干 - 非阻塞思路（需配合事件循环）：
async with aiofiles.open('huge.log') as f: data = await f.read()—— 读文件时可同时处理其他协程
关键不在“是否快”，而在“能否把等待时间利用起来”。
