asyncio.TaskGroup 如何处理子任务取消时的整体传播

不会。TaskGroup.cancel()仅发起取消请求，子任务需在await点响应CancelledError；阻塞操作或未await协程会导致卡住，资源清理须显式处理，嵌套group需手动传播取消信号。

asyncio.TaskGroup.cancel() 会立即终止所有子任务吗

不会。调用 TaskGroup.cancel() 并不直接触发子任务的取消，而是向整个 TaskGroup 发起取消请求；真正传播取消信号依赖于子任务是否在 await 点响应 CancelledError。如果某个子任务正阻塞在非协程操作（如 time.sleep()、纯 CPU 循环）或未被 await 的协程对象上，它不会及时退出，导致 TaskGroup 的 __aexit__ 卡住，直到该任务自然完成或超时。

• TaskGroup 内部使用 asyncio.shield() 包裹子任务的 await，所以子任务必须自己处理 CancelledError，不能靠外层“强制杀掉”
• 子任务中未被 await 的协程（例如忘了加 await 的 asyncio.sleep(1)）会被静默忽略，既不执行也不报错，但也不会响应取消
• 若子任务在 try/except CancelledError 中吞掉异常且没重新抛出，取消传播就中断了

子任务里怎么正确响应取消并清理资源

关键是在每个可能被取消的 await 点之后，确保资源释放逻辑能被执行——不能只靠 finally 块，因为如果任务被取消时正卡在某个 await 上（比如 await queue.get()），finally 不会运行，除非你显式捕获 CancelledError 并手动清理。

• 在 try 块中 await 可能挂起的操作，在 except CancelledError 中显式关闭连接、取消 pending future、释放锁等
• 避免在 finally 里做带 await 的操作（如 await db.close()），那会导致二次取消风险；改用同步清理，或用 asyncio.create_task() 脱离当前取消上下文
• 对长时间运行的 CPU 密集型逻辑，定期插入 await asyncio.sleep(0) 或检查 asyncio.current_task().cancelled()

为什么 await task_group.create_task(...) 后不能直接 await 单个任务

因为 TaskGroup.create_task() 返回的是一个尚未被调度的 asyncio.Task 对象，但它和 TaskGroup 生命周期绑定；如果你在 TaskGroup 上下文外 await 它，就脱离了取消传播链——即使 TaskGroup 已取消，该任务仍可能继续运行，且 TaskGroup.__aexit__ 会等待它结束（哪怕它已不该再跑）。

码上飞

码上飞（CodeFlying） 是一款AI自动化开发平台，通过自然语言描述即可自动生成完整应用程序。

下载

• 永远只在 async with TaskGroup() as tg: 内部启动任务，并让它们自然完成或被取消
• 不要把 tg.create_task(...) 的返回值保存到外部变量再 await —— 这相当于绕过了 TaskGroup 的协调机制
• 如果需要提前拿到结果，用 asyncio.wait_for(task, timeout)，但注意 timeout 触发后 task 仍属于 TaskGroup，其取消由 group 统一管理

嵌套 TaskGroup 时取消如何逐层向上冒泡

取消信号不会自动跨 TaskGroup 边界传播。父 TaskGroup 取消，只会取消它直接创建的子任务；如果某个子任务内部又建了新的 TaskGroup，那个内层 group 不会收到父级的取消信号，除非你手动把 CancelledError re-raise 或调用内层 task_group.cancel()。

• 嵌套场景下，建议在外层 except CancelledError 中显式调用内层 task_group.cancel()，然后 await task_group 等待其退出
• 不要依赖“父 cancel → 子 task cancel → 子 task 里的 tg 自动 cancel”，这不会发生
• 内层 TaskGroup 的生命周期必须完全包裹在外层任务的 try/except 块中，否则取消时可能引发 RuntimeError: Task group is closed