协程“饿死”是事件循环资源分配失衡所致：某协程长期占用CPU或阻塞I/O，致其他协程无法调度；常见原因包括误用time.sleep()、CPU密集计算未移交控制权、await未完成Future、任务未被显式调度等。
协程“饿死”不是语法错误，而是事件循环资源分配失衡的直观表现：某个协程长期占用 CPU 或阻塞 I/O，导致其他协程得不到调度机会。
time.sleep() 直接冻结整个事件循环
这是最常见也最容易被忽略的饥饿源头。asyncio 的事件循环是单线程协作式调度，time.sleep() 是同步阻塞调用，它会让当前线程（也就是事件循环所在线程）彻底停摆，所有协程暂停执行。
- 现象：启动 10 个
asyncio.create_task()，其中 1 个用了time.sleep(5)，其余 9 个会卡住整整 5 秒才开始执行 - 正确替代：必须用
await asyncio.sleep(5)，它是异步可等待对象，会主动让出控制权 - 注意：
asyncio.sleep()只模拟等待，不解决真实 CPU 密集型任务；若真要算 π 的百万位，它照样饿死别人
CPU 密集型操作不移交控制权
哪怕没写 time.sleep()，纯计算也会饿死协程——只要它不主动 await，事件循环就无法插入调度点。
- 场景：在
async def函数里做图像缩放、JSON 解析大文件、加密哈希等 - 问题本质：Python 的 async/await 不等于多线程，它不自动切片 CPU 时间片
- 解法只有两个：把计算丢给线程池（
loop.run_in_executor(None, heavy_func, *args)），或改用支持异步原语的库（如orjson替代json） - 警告：别试图在循环里加
await asyncio.sleep(0)来“让出”，这属于 hack，不可靠且增加调度开销
await 一个未完成的 Future 或挂起的协程
表面看是 await，实际可能陷入无限等待，间接造成饥饿。典型如忘记启动子任务、或错误地 await 了未被调度的协程对象。
立即学习“Python免费学习笔记（深入）”；
- 错误模式：
task = my_coro()然后await task—— 这没问题；但若写成await my_coro（漏了括号），就会报TypeError: object ... can't be used in 'await' expression，而如果静默吞掉这个异常，后续逻辑就卡住 - 更隐蔽的是：
await asyncio.wait_for(some_network_call(), timeout=10)中，底层连接因 DNS 慢或防火墙策略卡在 SYN 阶段，wait_for无法真正中断底层 socket 阻塞，此时不仅该协程饿死，还可能拖垮整个连接池 - 建议：对所有外部调用设超时，且优先使用已封装超时逻辑的异步客户端（如
aiohttp.ClientSession自带timeout参数）
任务未被显式调度或被意外取消
协程对象本身不会运行，只有被 event loop 接管后才算“出生”。没被调度 = 从未存在过，自然谈不上饿死——但它会让开发者误以为“写了 async 就等于并发”。
- 典型疏漏：定义了
async def fetch_user(): ...，但在主函数中只写fetch_user()而没await或create_task()，该协程根本不会执行 - 另一个坑：
asyncio.create_task()返回的Task对象若未被 await、未被加入asyncio.gather()、也没被保存引用，可能被 GC 回收，导致任务静默消失（尤其在短生命周期脚本中） - 验证方法：运行前加一句
print(asyncio.all_tasks())，确认你认为该跑的任务确实在列表里
饥饿问题难调试，因为它不报错、不崩溃，只悄悄变慢。最有效的防御不是加更多 await，而是从第一行代码就明确：这个函数是否真的需要异步？它的耗时瓶颈在 I/O 还是 CPU？有没有现成的异步替代品？没有银弹，只有每次调用前的那一次判断。
