兄弟，我来给你掰扯清楚这个事儿！你的代码里藏着asyncio新手最容易踩的一个坑——同步阻塞调用把事件循环给“焊死”了，这直接导致取消信号根本没机会被处理。

先把你的代码贴出来方便分析：

import asyncio
import time

async def blocking_task():
    time.sleep(5)   # Intentional blocking call
    return "done"

async def cancellable_task():
    try:
        await asyncio.sleep(10)
    except asyncio.CancelledError:
        print("cancellable_task cancelled")
        raise

async def main():
    task1 = asyncio.create_task(blocking_task())
    task2 = asyncio.create_task(cancellable_task())

    try:
        await asyncio.gather(task1, task2)
    except Exception as e:
        print("exception:", e)

asyncio.run(main())

核心原因：事件循环被同步调用卡住了 #

asyncio的事件循环是个单线程调度器，所有任务切换、信号处理（包括取消信号）都有个前提：当前执行的任务片段必须主动把控制权交还给事件循环。

你看blocking_task里的time.sleep(5)——这是个纯同步阻塞调用，它会直接占住整个线程，让事件循环完全没法干别的。哪怕你在这段时间里主动触发task2.cancel()，事件循环也根本没机会去处理这个取消请求，因为它被time.sleep死死卡住了，连调度其他任务的空隙都没有。

而asyncio.gather的取消传播逻辑，完全依赖事件循环的正常调度。当事件循环被同步阻塞“锁死”时，别说取消信号，所有异步相关的逻辑都得暂停，直到同步阻塞调用跑完，控制权回到事件循环手里为止。

为啥asyncio.sleep能响应取消？ #

因为asyncio.sleep是异步可中断的，它执行时会主动把控制权交还给事件循环，事件循环在这时候才能处理各种信号（包括取消）。但time.sleep是同步的，它直接把线程占满，事件循环根本插不上手。

怎么解决这个问题？ #

给你两个关键建议：

• 永远别在asyncio任务里用同步阻塞调用（比如time.sleep、同步IO、CPU密集计算），如果必须用，把它们丢到asyncio.to_thread()或者线程池里执行，这样不会阻塞事件循环：

  async def blocking_task():
      await asyncio.to_thread(time.sleep, 5)  # 把同步阻塞移到单独线程
      return "done"
  

  这样修改后，blocking_task会立即把控制权还给事件循环，事件循环就能正常处理cancellable_task的取消信号了。
• 所有长时间运行的操作，必须是能主动交还控制权的异步操作，这是asyncio能正常工作的基础。同步阻塞操作是asyncio的天敌，会彻底打乱它的调度逻辑。

补充一句：你原代码里没加主动取消的逻辑，但就算你加了（比如main里过1秒调用task2.cancel()），只要blocking_task还在跑time.sleep(5)，取消信号也得等5秒后事件循环恢复才能被处理——这就是你觉得“取消信号没立即传播”的本质原因。