在 asyncio 中应优先使用 TaskGroup 实现关联任务树的优雅取消，它自动级联取消并确保清理；若不可用，则通过共享 Event 手动传播取消信号，并用 try/finally 或异步上下文管理器保障资源释放。
在 asyncio 中优雅取消一组相互关联的任务树，关键在于统一的取消信号传播、任务间协作式退出、以及资源清理的确定性保障。不能只靠 task.cancel() 粗暴中断，而要让父任务能通知子任务、子任务能反馈完成状态、所有层级都能执行必要的清理逻辑。
使用结构化并发（trio 风格）或 asyncio.create_task + cancel_scope 模拟
Python 3.11+ 原生支持 asyncio.TaskGroup，是处理关联任务树最推荐的方式。它自动实现“一损俱损”：任一子任务异常或被取消，整个组会被取消；所有子任务退出后，TaskGroup 才真正结束。
- 用
async with asyncio.TaskGroup() as tg:包裹任务启动逻辑 - 子任务通过
tg.create_task(coro)启动，自动绑定到该组生命周期 - 外部调用
tg.cancel()（Python 3.12+）或抛出BaseException（如KeyboardInterrupt）可触发级联取消 - 每个子协程需捕获
asyncio.CancelledError，执行清理后重新抛出（或静默退出）
手动管理父子关系：传递 cancellation token 或共享 Event
当无法使用 TaskGroup（如需更细粒度控制、跨事件循环、或兼容旧版本），可显式建模取消依赖关系。
- 创建一个
asyncio.Event作为“取消信号灯”，父任务启动前设为未设置状态 - 将该
Event传给所有子任务；子任务在关键等待点轮询if event.is_set(): raise asyncio.CancelledError - 父任务调用
event.set()后，主动await asyncio.gather(*children, return_exceptions=True)等待子任务退出 - 避免直接调用
task.cancel()后不 await —— 这会导致取消未完成就被忽略
确保清理逻辑可靠执行：使用 async context manager 或 finally 块
无论取消如何发生，I/O 资源（如连接、文件句柄）、状态标记、锁等必须释放。
- 在子协程中用
try/finally包裹核心逻辑，清理代码放在finally中 - 对可复用资源（如数据库连接池、HTTP session），封装成异步上下文管理器（
__aenter__/__aexit__），确保__aexit__在取消时仍被调用 - 慎用
asyncio.shield()：它会阻止取消传播，仅适用于“绝对不能中断”的原子操作（如关闭连接），但会破坏任务树整体一致性，不宜滥用
监控与调试：识别悬挂任务和取消盲区
取消失败常因协程未响应 CancelledError、阻塞了事件循环、或陷入无限等待。
- 启用
asyncio.get_event_loop().set_debug(True)，运行时会警告未处理的取消和长时间运行的协程 - 定期检查
asyncio.all_tasks()，过滤出task.done() == False and task.cancelled() == False的“卡住任务” - 对
asyncio.sleep()、queue.get()、stream.read()等挂起点，显式添加超时并检查取消信号
