asyncio.shield 必须用于保护正在运行的 Task 免受外部取消影响；它包装任务实例而非协程调用，拦截外部 cancel 信号但不阻止协程内主动退出，且不能与 wait_for 混用以防竞态。
asyncio.shield 什么时候必须用？
当你有一个正在运行的 asyncio.Task，但外部逻辑（比如超时、用户中断、父协程取消）可能调用 cancel()，而你又不希望它真的被取消——这时 asyncio.shield() 就是唯一可靠的选择。它不是“防取消”的万能开关，而是把一个协程包装成“不可被外部 cancel() 影响”的代理任务。
shield 不等于 await，别直接 await shield() 返回值
asyncio.shield() 返回的是一个 Awaitable，不是普通协程对象，更不是 Task。如果你写 await asyncio.shield(some_coro())，看起来没问题，但一旦外部调用 task.cancel()，some_coro() 仍会收到 CancelledError —— 因为 shield() 包裹的是协程调用本身，而不是它启动后的执行过程。
正确做法是先创建任务，再用 shield() 包裹该任务：
task = asyncio.create_task(long_running_job()) shielded = asyncio.shield(task) await shielded
这样即使你后续调用 task.cancel() 或其他地方触发取消，long_running_job() 的执行不会中断。
立即学习“Python免费学习笔记（深入）”；
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
shield 被取消时会发生什么？
asyncio.shield() 自身可以被取消，但它会把取消信号“拦截”并延迟到内部协程自然结束（或抛出异常）。这意味着：
- 如果内部协程已结束，
shielded立即抛出CancelledError - 如果内部协程还在跑，
shielded暂时不抛错，但它的done()仍是False，直到内部完成 - 若内部协程自己主动 raise
CancelledError（比如响应了asyncio.current_task().cancelled()），shield()不会阻止——它只挡外部 cancel，不挡协程内主动退出
常见误用：和 timeout 混搭时的陷阱
很多人想“用 shield() 保关键任务，同时给整体加 timeout”，比如：
try:
await asyncio.wait_for(asyncio.shield(db_commit()), timeout=5)
except asyncio.TimeoutError:
# 这里 db_commit() 其实还在跑！
pass问题在于：wait_for 取消的是 shield() 包裹的对象，而 shield() 会抑制这个取消，导致 db_commit() 继续执行——但你的主流程已认为它失败了。结果可能是重复提交、状态不一致。
真正安全的做法是：
- 用
asyncio.create_task()显式启动关键任务 - 用
asyncio.shield()包裹该 task 对象（不是协程调用） - 用
asyncio.wait()+return_when=asyncio.FIRST_COMPLETED来协调 timeout 和 shielded 任务 - 确保 timeout 分支不干扰 shielded 任务的生命周期（比如不要调它的
cancel()）
关键点始终只有一个：shield 必须作用于一个**正在运行的任务实例**，而不是协程调用表达式；且它不解决竞态、不替代合理错误处理，只是给取消信号加一道缓冲层。
