asyncio.create_task()后安全取消需调用task.cancel()并await task或asyncio.wait_for()，否则取消不生效；shield()仅拦截外部取消信号，不阻止内部取消；wait_for超时后须手动cancel并await清理；gather默认取消全部任务，需return_exceptions=true才隔离异常。
asyncio.create_task() 后怎么安全取消
直接调用 task.cancel() 是唯一可靠方式，但必须配合 await task 或 asyncio.wait_for() 才能真正触发取消逻辑。不 await 的话，任务可能还在跑，只是被标记为“待取消”。
- 取消后必须
await task，否则异常（CancelledError）不会抛出，协程也不会退出 - 如果任务正在执行 CPU 密集型操作（比如没加
await asyncio.sleep(0)的循环），cancel()会失效——它只能在await点生效 - 别用
task.done()判断是否结束：刚调用cancel()时它返回False，但任务其实已被中断；应检查task.cancelled()
为什么 asyncio.shield() 会让 cancel 失效
asyncio.shield() 的作用是让被包裹的协程“免疫”外部取消，常用于清理逻辑或关键子任务。但它不是万能保护罩——如果被 shield 的协程自己主动 raise CancelledError，或者内部有未处理的取消传播，照样会退出。
-
shield()只拦截父任务传来的取消信号，不阻止子任务内部的取消或超时 - 常见误用：把整个主逻辑包进
shield()，结果取消完全不起作用，任务卡死 - 正确用法只包裹真正不能中断的部分，比如
await db.close()或await file.close()
asyncio.wait_for() 超时后任务没结束怎么办
asyncio.wait_for(task, timeout) 超时后，task 并不会自动取消，只是抛出 asyncio.TimeoutError。你得手动处理后续：要么 await task 等它自然结束，要么显式 task.cancel()。
- 漏掉这一步会导致“幽灵任务”继续运行，占用资源、修改状态，甚至引发竞态
- 推荐写法：
try: result = await asyncio.wait_for(task, timeout=5) except asyncio.TimeoutError: task.cancel() await task # 确保清理完成 - 注意
wait_for自身也会被外层取消，此时它内部的 task 不受影响，仍需单独处理
asyncio.gather() 中某个任务被取消，其他任务还继续吗
默认情况下，asyncio.gather() 遇到任一任务取消，会立即取消所有剩余任务。这是它的默认行为，不是 bug。
立即学习“Python免费学习笔记（深入）”；
- 想让其他任务继续运行，必须传
return_exceptions=True，这样取消会变成CancelledError实例，不中断整体执行 - 但要注意：即使设置了
return_exceptions=True，被取消的任务也不会自动清理——你仍要检查结果里有没有CancelledError，并决定是否await它做善后 - 别依赖
gather的“并发性”来规避取消影响，它的取消传播逻辑很坚决
取消不是发个信号就完事，关键是控制权交还给事件循环的时机，以及你是否真等到了那个 await 点。很多人卡在“调了 cancel 却没反应”，问题往往出在没 await，或者协程根本没 yield 控制权。