协程能用阻塞函数吗？会卡死吗？

协程中绝不能直接调用`time.sleep()`等同步阻塞函数，否则会彻底冻结整个事件循环，导致所有并发任务停滞——这不是切换失效，而是CPU时间片被单一线程独占、其他协程完全丧失执行机会；正确做法是统一使用`await asyncio.sleep()`及原生异步库（如aiohttp、aiosqlite、aiopath），仅在万不得已时谨慎使用`asyncio.to_thread()`并直面线程安全、上下文丢失和性能损耗等隐患；真正决定协程是否“真异步”的，不是函数名或表象，而是其底层是否涉及系统I/O或主动让出CPU，唯有穿透表象、敬畏调度机制，才能避免高并发场景下悄然退化为串行执行的致命陷阱。

协程里调用 time.sleep() 会卡住整个事件循环

不能直接用。Python 的 asyncio 协程是单线程协作式调度，一旦执行了像 time.sleep() 这样的同步阻塞函数，当前线程就彻底停住，所有其他协程都得干等——不是“切换失效”，是根本没机会切。

常见错误现象：async def fetch_data(): time.sleep(2); return "done" 看起来只延迟一个协程，实际会让整个 asyncio.run() 或 loop.run_until_complete() 卡死 2 秒，哪怕你起了 10 个并发任务也全被拖住。

• 正确做法：用 await asyncio.sleep(2) 替代 time.sleep(2)
• 所有标准库阻塞 I/O（如 requests.get()、open() 读大文件、subprocess.run()）都不能在协程里直呼，必须换异步等价物（aiohttp、aiopath、asyncio.to_thread() 等）
• Python 3.9+ 可用 asyncio.to_thread() 包一层，但它是把阻塞操作扔进线程池跑，有开销，不是真异步

asyncio.to_thread() 不是万能解药，小心线程安全和上下文丢失

它确实能让你在协程里“塞进”一个阻塞调用，但代价明确：启动线程、传递参数、等待结果、再切回事件循环。性能不如原生异步，且容易踩坑。

使用场景：临时兼容旧代码、调用没有异步封装的 C 扩展、或极少数无法改写的阻塞逻辑。

• 传入函数不能依赖协程局部状态（比如 contextvars.ContextVar 在子线程里默认不继承，要手动 copy）
• 如果阻塞函数内部用了全局变量或共享资源，要考虑线程安全，asyncio.to_thread() 不自动加锁
• 错误类型不变，但堆栈里会多一层 concurrent.futures 相关帧，调试时注意区分是原函数报错还是线程调度失败
• 示例：await asyncio.to_thread(os.path.getsize, "/huge/file.bin") 比直接 os.path.getsize() 多一次线程切换，但比卡主线程强

第三方库阻塞调用（如 requests）必须替换，别信“小请求没事”

有人试过 await asyncio.to_thread(requests.get, url)，觉得短连接快就忽略问题。实际上只要并发量上去或网络抖动，线程池就会撑满，后续协程排队等线程，吞吐骤降，还可能触发 concurrent.futures.ThreadPoolExecutor 的 timeout 异常。

真实使用场景：HTTP 请求、数据库查询、文件读写——这些都有成熟异步替代方案。

• HTTP：换 aiohttp 或 httpx.AsyncClient，别碰 requests
• SQLite：用 aiosqlite；PostgreSQL 用 asyncpg；MySQL 用 aiomysql 或 mysql-async
• 文件操作：小文件可 await asyncio.to_thread(open...)，大文件或高频 IO 建议用 aiopath 或直接走 asyncio.loop.run_in_executor() 自定义线程池
• 别自己封装 requests + to_thread 当长期方案，维护成本高，性能边界模糊

协程“看起来像阻塞”的代码，未必真阻塞——但得看底层实现

有些函数名带 sync 或行为像同步，实际可能是异步友好的。比如 pathlib.Path.read_text() 是同步的，但 aiopath.Path.read_text() 返回的是 Awaitable[str]，必须 await；而 json.loads() 是纯 CPU 计算，不 IO，所以能在协程里直接调，不会影响调度。

关键判断依据：是否涉及系统调用（read/write/connect/accept）、是否主动让出 CPU（sleep/wait）、是否依赖外部服务响应。

• 纯计算类（json.loads、re.findall、sorted()）可以放心在协程里用
• 任何封装了 open()、socket、subprocess 的函数，先查文档是否标了 async，没标就默认阻塞
• 不确定时，用 asyncio.debug = True 启动，或加 asyncio.current_task().get_coro() 日志，观察是否长时间没 yield

协程调度的脆弱点不在语法，而在对“谁在控制 CPU 时间片”的误判。一个没 await 的 time.sleep、一次漏掉的 await、或者对某个三方函数“应该没问题”的假设，都足以让整个并发模型退化成串行。

今天关于《协程能用阻塞函数吗？会卡死吗？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于Workerman的内容请关注golang学习网公众号！