在Python的asyncio编程中，task.cancel()是用来请求取消一个正在运行的协程任务的方法。很多人在调用后发现协程内部抛出了CancelledError，或者资源没有被正确释放，这背后涉及事件循环、任务状态和协程中断机制的协作方式。本文将详细说明cancel()的行为原理，以及如何在协程被取消时安全地清理资源并退出。
一、task.cancel()到底做了什么
当我们调用一个Task对象的cancel()方法时，并没有立刻终止协程的执行，而是向该任务发送了一个取消请求。事件循环在下次调度这个任务时，会在协程当前暂停的await表达式处抛出CancelledError异常。换句话说，cancel()是“请求式”的，协程必须运行到下一个可被中断的await点才会真正响应取消。
如果协程内部没有await语句，或者长期阻塞在CPU密集型代码中不交出控制权，那么cancel()可能不会及时生效。这也是为什么在编写异步代码时，不能在协程里写死循环而不加await asyncio.sleep(0)之类让出控制的语句。下面的代码展示了基本的取消行为：
import asyncio
async def worker():
try:
print("工作开始")
await asyncio.sleep(5)
print("工作完成")
except asyncio.CancelledError:
print("收到取消请求")
raise
async def main():
task = asyncio.create_task(worker())
await asyncio.sleep(1)
task.cancel()
try:
await task
except asyncio.CancelledError:
print("主函数捕获到任务取消")
asyncio.run(main())
在上面的例子中，worker协程在sleep期间被取消，sleep抛出CancelledError，被except捕获后重新raise，从而保证任务状态变为cancelled。如果我们吞掉了CancelledError而不重新抛出，任务会被标记为正常完成，这可能违反asyncio的约定。
二、为什么必须处理CancelledError
CancelledError是asyncio用来传递取消信号的特殊异常，从Python 3.8起它继承自BaseException而不是Exception。这意味着如果用except Exception来捕获，根本抓不到它。很多初学者写try...except Exception把错误吞掉，结果任务无法正常取消，程序关闭时卡住。
正确处理方式是在协程中捕获CancelledError做必要的清理，然后再次抛出。如果使用了async with或with语句管理资源，可以在退出上下文时自动清理。下面展示一个错误示范和正确示范的对比：
import asyncio
# 错误示范：吞掉异常
async def bad_worker():
try:
await asyncio.sleep(10)
except asyncio.CancelledError:
print("忽略取消") # 没有raise，任务会显示完成
# 正确示范：清理后重抛
async def good_worker():
try:
await asyncio.sleep(10)
except asyncio.CancelledError:
print("清理资源中")
# 假设关闭文件或网络连接
raise
在good_worker中，我们捕获到CancelledError后执行清理逻辑，然后raise让取消状态向上传递。这样外层await task时也能正确收到取消信号，整个任务生命周期是可控的。
三、使用finally与异步上下文安全清理
无论协程是因正常结束、出错还是被取消，finally块中的代码都会执行。因此把资源释放逻辑放在finally里是最基础的做法。对于支持异步上下文管理器的对象，优先使用async with，因为它的__aexit__在取消时也会被调用。
以下示例模拟一个数据库连接在任务取消时的安全退出。我们定义一个异步上下文管理器，并在其中进行连接和关闭：
import asyncio
class AsyncDB:
async def __aenter__(self):
print("打开数据库连接")
return self
async def __aexit__(self, exc_type, exc, tb):
print("关闭数据库连接")
if exc_type is asyncio.CancelledError:
print("因取消而关闭")
return False
async def db_task():
async with AsyncDB() as db:
await asyncio.sleep(5)
print("查询完成")
async def main():
task = asyncio.create_task(db_task())
await asyncio.sleep(1)
task.cancel()
try:
await task
except asyncio.CancelledError:
print("任务已取消")
asyncio.run(main())
运行这段代码会看到，即使db_task在sleep中被取消，async with依然触发了__aexit__，数据库连接被关闭。这种方式比手写try...finally更不容易遗漏，也更符合Python的惯用法。
如果某些资源不支持异步上下文，也可以用常规try...finally结合同步关闭方法，但需要注意关闭操作本身应当是快速的，不要在其中await可能再次被取消的长时间调用，否则清理过程会被打断。
四、在超时与关闭信号中统一处理
实际服务中，取消往往来自asyncio.wait_for超时或者接收退出信号。wait_for内部就是对传入的task调用cancel()。我们可以在任务外统一捕获CancelledError并做进程级清理，比如停掉后台定时任务。示例如下：
import asyncio
async def long_job():
await asyncio.sleep(30)
return "done"
async def main():
try:
result = await asyncio.wait_for(long_job(), timeout=3)
print(result)
except asyncio.TimeoutError:
print("任务超时取消")
except asyncio.CancelledError:
print("被外部取消")
asyncio.run(main())
wait_for在超时会取消内部任务并抛出TimeoutError，此时long_job里的CancelledError已经被wait_for吸收并转为TimeoutError。如果我们在long_job内部有finally清理，它依然会执行。这种分层处理让取消逻辑既局部又整体可控。
总结来说，task.cancel()只是发信号，CancelledError是信号载体，安全退出靠的是协程内的捕获重抛与资源上下文管理。把这些机制组合起来，异步程序才能在各种中断场景下不泄漏资源、不卡进程。
Python协程task_cancelCancelledError修改时间：2026-08-04 02:51:14