不会。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__ 会等待它结束（哪怕它已不该再跑）。
- 永远只在
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
TaskGroup 发起请求，到每个子任务识别并响应 CancelledError，再到嵌套结构中手动桥接信号——漏掉任意一环，都会导致任务滞留或资源泄漏。 
