Python的I/O阻塞本质是操作系统同步阻塞模型所致，并非Python或GIL造成；open()、recv()等调用底层系统调用，数据未就绪时线程被内核挂起；GIL在I/O时会释放，不影响并发；默认阻塞的包括文件、socket、subprocess和标准流，可通过非阻塞模式、超时、asyncio或多线程规避。
Python 的 I/O 阻塞，本质不是 Python 本身造成的，而是底层操作系统对文件、网络、终端等资源的访问方式决定的——默认采用 同步阻塞（synchronous blocking） 模型。
系统调用层面的阻塞
Python 的 open()、read()、recv() 等函数最终会调用操作系统的系统调用（如 read(2)、recvfrom(2)）。当数据尚未就绪（比如磁盘还没读完、网卡缓冲区为空、键盘还没按键），内核会让当前线程进入睡眠状态，交出 CPU，直到事件就绪或超时。这个“等待”过程就是阻塞的根源。
例如：
- 读取一个普通文件时，若数据在磁盘上且未被缓存，需等待磁盘寻道+读取，期间线程挂起；
- 调用
socket.recv(1024)时，若对端没发数据，内核不返回，Python 线程就卡住； - 从
sys.stdin读取时，实际是读/dev/tty，没有输入就一直等。
Python 的 GIL 不是主因
很多人误以为 GIL（全局解释器锁）导致 I/O 阻塞。其实相反：I/O 阻塞时，CPython 会 主动释放 GIL，让其他线程可以运行。GIL 只限制 CPU 密集型代码的并行，不影响 I/O 等待期间的线程切换。真正让程序“卡住”的，是线程在系统调用中休眠，而非被 GIL 锁住。
立即学习“Python免费学习笔记（深入）”；
哪些 I/O 默认阻塞？
绝大多数标准 I/O 接口默认阻塞：
- 文件对象：
f = open("data.txt"); f.read()（普通文件、管道、终端）； - 套接字：
s = socket.socket(); s.recv(1024)（除非设为非阻塞）； - 子进程通信：
subprocess.Popen().communicate()； - 标准流：
input()、sys.stdin.readline()。
例外：某些特殊文件描述符（如 `epoll`、`kqueue` 对象）或显式配置为非阻塞（os.set_blocking(fd, False)）则不会阻塞。
如何避免阻塞？
核心思路是绕过“等数据来了再继续”的默认行为：
-
非阻塞模式：设置文件描述符为非阻塞（
socket.setblocking(False)），再配合轮询或事件循环； -
超时控制：使用
timeout参数（如socket.settimeout(5)或open()不支持，但socket和subprocess支持）； -
异步 I/O：用
asyncio+await，底层调用epoll/kqueue/IOCP实现单线程并发； - 多线程/多进程：把阻塞 I/O 放到独立线程中执行，主线程不受影响（注意：线程仍会阻塞，只是不阻塞整个程序）。
关键点：阻塞与否由操作系统决定，Python 只是忠实传递语义；改写行为必须显式干预（设非阻塞、加超时、换异步 API）。
