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()，而是判断哪段逻辑真的「不能被中断」，以及中断发生时系统是否还能保持一致状态。 
