Python 协程里怎么正确处理取消（asyncio.CancelledError）

协程被取消时一定会抛出 asyncio.CancelledError，它继承自 BaseException，需显式捕获；finally 块总执行，适合清理；子任务不会自动取消，需手动管理；测试需确保协程处于 await 状态。

协程被取消时一定会抛出 asyncio.CancelledError

这不是可选行为，而是 asyncio 的核心机制：只要任务被 cancel()，且该任务正在等待（如 await asyncio.sleep(1)），事件循环就会在下一次调度时主动抛出 asyncio.CancelledError。它继承自 BaseException（不是 Exception），所以 except Exception: 捕获不到——这是最常踩的坑。

• 必须显式写 except asyncio.CancelledError: 或 except BaseException:（不推荐后者，会吞掉其他严重异常）
• 如果协程里有 try/finally，fin

  

  ally 块一定会执行，无论是否被取消——适合做资源清理
• 在 except asyncio.CancelledError: 中再抛出该异常（raise），是允许协程“合作式退出”的标准做法

在 async with 和 async for 中取消可能被延迟

异步上下文管理器（__aenter__/__aexit__）和异步迭代器（__aiter__/__anext__）内部若存在阻塞或长耗时 await，取消信号可能要等当前 await 完成后才生效。比如：

async def slow_iter():
    for i in range(5):
        await asyncio.sleep(2)  # 取消请求在此处不会立即中断
        yield i

• 不要依赖“立刻停止”，而要在关键步骤插入 if asyncio.current_task().cancelled(): raise asyncio.CancelledError()
• 使用 asyncio.wait_for(coro, timeout) 包裹慢操作，比手动轮询更可靠
• 自定义 AsyncContextManager 时，在 __aexit__ 中检查 exc_type is asyncio.CancelledError，决定是否继续清理

取消传播：子任务不会自动被取消

父协程被取消，其启动的子任务（如用 asyncio.create_task() 启动的）默认不会被取消——它们继续运行，可能造成资源泄漏或状态不一致。

• 显式跟踪子任务：保存 task 对象，在父协程的 finally 或 except asyncio.CancelledError: 中调用 task.cancel() 并 await asyncio.wait_for(task, timeout=1)
• 用 asyncio.gather(..., return_exceptions=True) 启动多个任务，它会在任一子任务被取消时，自动尝试取消其余任务（但仍有竞态，需配合超时）
• 避免用 asyncio.ensure_future() 替代 create_task()：前者不绑定到当前事件循环上下文，取消行为更难预测

测试取消逻辑不能只靠 task.cancel()

直接调用 task.cancel() 只是设置取消标记，异常实际发生在下一次 await；如果协程已经结束或没 await，CancelledError 根本不会抛出。

• 真实测试场景应让协程处于等待中：用 asyncio.sleep(10) 或 asyncio.Event().wait() 卡住，再 cancel
• 用 asyncio.run_coroutine_threadsafe() + 线程 sleep + cancel，模拟并发取消更贴近生产环境
• 注意 Python 3.11+ 引入了 asyncio.timeout() 上下文管理器，比手写 wait_for 更清晰，但底层仍依赖同一套取消机制

真正难的是清理逻辑本身是否幂等、是否持有锁、是否在取消途中又触发新 await——这些没法靠语法糖解决，得靠具体场景反复验证。