Pythonasyncio任务取消全攻略

本文深入剖析了 Python asyncio 中任务取消的常见误区与正确实践，强调 cancel() 只是发出取消信号，真正生效必须依赖 await 触发事件循环调度；详解了 shield() 的局限性（仅屏蔽外部取消、不防内部中断）、wait_for() 超时后必须手动 cancel 并 await 清理以避免幽灵任务，以及 gather() 默认全量取消的激进行为与 return_exceptions=True 的隔离策略，直击开发者“调了 cancel 却没反应”的核心痛点——根本原因往往在于未 await 任务或协程长期阻塞未让出控制权。

asyncio.create_task() 后怎么安全取消

直接调用 task.cancel() 是唯一可靠方式，但必须配合 await task 或 asyncio.wait_for() 才能真正触发取消逻辑。不 await 的话，任务可能还在跑，只是被标记为“待取消”。

• 取消后必须 await task，否则异常（CancelledError）不会抛出，协程也不会退出
• 如果任务正在执行 CPU 密集型操作（比如没加 await asyncio.sleep(0) 的循环），cancel() 会失效——它只能在 await 点生效
• 别用 task.done() 判断是否结束：刚调用 cancel() 时它返回 False，但任务其实已被中断；应检查 task.cancelled()

为什么 asyncio.shield() 会让 cancel 失效

asyncio.shield() 的作用是让被包裹的协程“免疫”外部取消，常用于清理逻辑或关键子任务。但它不是万能保护罩——如果被 shield 的协程自己主动 raise CancelledError，或者内部有未处理的取消传播，照样会退出。

• shield() 只拦截父任务传来的取消信号，不阻止子任务内部的取消或超时
• 常见误用：把整个主逻辑包进 shield()，结果取消完全不起作用，任务卡死
• 正确用法只包裹真正不能中断的部分，比如 await db.close() 或 await file.close()

asyncio.wait_for() 超时后任务没结束怎么办

asyncio.wait_for(task, timeout) 超时后，task 并不会自动取消，只是抛出 asyncio.TimeoutError。你得手动处理后续：要么 await task 等它自然结束，要么显式 task.cancel()。

• 漏掉这一步会导致“幽灵任务”继续运行，占用资源、修改状态，甚至引发竞态
• 推荐写法：

  try:
      result = await asyncio.wait_for(task, timeout=5)
  except asyncio.TimeoutError:
      task.cancel()
      await task  # 确保清理完成
  

• 注意 wait_for 自身也会被外层取消，此时它内部的 task 不受影响，仍需单独处理

asyncio.gather() 中某个任务被取消，其他任务还继续吗

默认情况下，asyncio.gather() 遇到任一任务取消，会立即取消所有剩余任务。这是它的默认行为，不是 bug。

• 想让其他任务继续运行，必须传 return_exceptions=True，这样取消会变成 CancelledError 实例，不中断整体执行
• 但要注意：即使设置了 return_exceptions=True，被取消的任务也不会自动清理——你仍要检查结果里有没有 CancelledError，并决定是否 await 它做善后
• 别依赖 gather 的“并发性”来规避取消影响，它的取消传播逻辑很坚决

取消不是发个信号就完事，关键是控制权交还给事件循环的时机，以及你是否真等到了那个 await 点。很多人卡在“调了 cancel 却没反应”，问题往往出在没 await，或者协程根本没 yield 控制权。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~