协程被取消时一定会抛出 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，finally块一定会执行，无论是否被取消——适合做资源清理 - 在
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 根本不会抛出。
立即学习“Python免费学习笔记（深入）”；
- 真实测试场景应让协程处于等待中：用
asyncio.sleep(10)或asyncio.Event().wait()卡住，再 cancel - 用
asyncio.run_coroutine_threadsafe()+ 线程 sleep + cancel，模拟并发取消更贴近生产环境 - 注意 Python 3.11+ 引入了
asyncio.timeout()上下文管理器，比手写wait_for更清晰，但底层仍依赖同一套取消机制
真正难的是清理逻辑本身是否幂等、是否持有锁、是否在取消途中又触发新 await——这些没法靠语法糖解决，得靠具体场景反复验证。
