阻塞io调用时线程挂起等待数据就绪，非阻塞io立即返回并抛出blockingioerror；实际高并发中需结合io多路复用（如select/epoll）与非阻塞io协同工作，asyncio即基于此机制封装。
阻塞IO和非阻塞IO的核心区别在于：调用IO操作（如读文件、收网络包）时，线程是否立即返回，还是必须等到数据就绪才能继续执行。
阻塞IO：等不到数据不放手
默认情况下，Python的大多数IO操作（file.read()、socket.recv()、sys.stdin.readline()等）都是阻塞的。一旦发起调用，当前线程会挂起，CPU让出执行权，直到满足条件（比如缓冲区有数据、连接建立完成、超时发生）才恢复运行。
例如：
– 调用 sock.recv(1024) 时，若网卡还没收到数据，线程就“卡住”，什么也不干；
– 打开一个大文件并调用 f.read()，如果磁盘响应慢，程序就停在那里。
优点是逻辑直白、代码易写；缺点是单线程下无法同时处理多个IO任务，资源利用率低。
非阻塞IO：试一下，不行就走
将IO对象设为非阻塞模式后（如 sock.setblocking(False)），每次调用IO函数都立刻返回——不管数据是否就绪。若无数据可读/可写，会抛出 BlockingIOError（Python 3.3+）或 error[EAGAIN/EWOULDBLOCK] 异常。
立即学习“Python免费学习笔记（深入）”；
你需要自己轮询、捕获异常、判断状态，再决定重试或做别的事。例如：
- 调用 sock.recv(1024) → 立即返回，有数据就拿，没数据就报 BlockingIOError；
- 你得在循环里反复尝试，或配合 select/poll/epoll 来知道“什么时候可以安全读”；
- 手动管理状态容易出错，且空转轮询浪费CPU。
真正实用的方案：IO多路复用 + 非阻塞IO
单独用非阻塞IO意义有限。实际高并发场景中，它常与 select、poll 或 epoll（Linux）/kqueue（macOS/BSD）配合使用：
- 先用 select() 询问“哪些socket有数据可读/可写/出错”；
- 只对返回就绪的socket，再调用非阻塞 recv/send —— 此时几乎不会触发 BlockingIOError；
- 这样既避免了阻塞等待，又规避了盲目轮询，实现单线程高效管理成百上千连接。
Python标准库的 asyncio 底层正是基于这套机制（在不同系统上自动选择最优多路复用接口），并封装了事件循环、协程调度等，让你不用直接操作 setblocking 或 select。
小结：别只看“阻塞与否”，要看协作方式
阻塞IO适合简单脚本或单任务工具；
非阻塞IO不是目的，而是配合多路复用实现高并发的必要环节；
现代Python开发更推荐用 asyncio 或成熟框架（如 aiohttp、FastAPI）来隐藏底层细节，专注业务逻辑。
