asyncio.shield 的使用场景解析

asyncio.shield() 仅阻断父任务取消信号的传播，不阻止协程内部因可取消挂起点（如await asyncio.sleep()）抛出CancelledError；必须在create_task()前包裹协程，且仅用于必须执行完的收尾逻辑。

asyncio.shield 不能防止 CancelledError 被抛出

它只是让被包裹的协程不被外部 cancel() 直接中断，但协程内部如果自己响应了取消信号（比如调用了 await asyncio.sleep() 并被取消），CancelledError 仍会冒泡出来。

常见错误现象：以为加了 shield() 就“绝对安全”，结果任务还是提前退出，日志里看到 CancelledError。

• 真正起作用的是「取消传播被阻断」——父任务取消时，shielded 协程不会收到取消通知；但它自己调用可取消挂起点（如 await asyncio.sleep(10)）时，仍可能因事件循环已取消该任务而抛出异常
• 典型使用场景：清理逻辑、日志上报、数据库连接关闭等必须跑完的操作
• 别对整个长流程套 shield()，只包最后那段「不可中断的收尾」

shield() 包裹位置错了就白搭

asyncio.shield() 必须在协程被调度前包裹，不是在 create_task() 之后补救。

错误写法：task = asyncio.create_task(some_coro()); shield(task) —— 这没用，shield() 返回的是一个新 awaitable，不是修改原 task。

• 正确做法是：task = asyncio.create_task(asyncio.shield(some_coro()))
• 或者直接 await：await asyncio.shield(some_coro())（此时当前协程会等它完成）
• 如果用 asyncio.wait() 等待多个任务，记得把 shielded 的协程也传进去，否则它可能被 wait 的 timeout 或 cancel 波及

和 asyncio.create_task() 配合时要注意引用丢失

一旦你用 asyncio.shield() 包裹协程再传给 create_task()，返回的 Task 对象就不再直接对应原始协程——它的取消行为被 shield 层拦截了，但 task.cancel() 依然生效（只是 shield 内部会忽略）。

容易踩的坑：你保存了这个 task 引用，然后 elsewhere 调了 task.cancel()，以为能立刻停掉它，结果它还在跑。

• task.cancel() 会成功返回 True，但 shielded 协程不受影响
• 想真正终止，得在 shielded 协程内部检查 asyncio.current_task().cancelled() 并主动退出
• 若需外部可控的“软终止”，不如用 asyncio.Event 或 asyncio.Queue 通信，别依赖 cancel

性能开销很小，但别滥用

asyncio.shield() 本身只是包装一层 awaitable，没有调度或上下文切换成本。问题出在误用导致逻辑变复杂。

比如在每层 await 都套 shield，或对纯 CPU 计算（非 await 表达式）用 shield——这既无效又误导后续维护者。

• 只在明确需要「跳过父级取消传播」的边界处用
• 注意它不解决竞态：两个 shielded 任务之间仍可能因共享状态冲突而行为异常
• Python 3.11+ 中，asyncio.timeout() 和 shield() 组合要小心——timeout 触发 cancel 时，shield 只挡一层，深层 await 仍可能中止

事情说清了就结束。真正难的从来不是加不加 shield()，而是判断哪段逻辑真的「不能被中断」，以及中断发生时系统是否还能保持一致状态。