asyncio.shield() 仅防止 await 点被外部取消中断，不阻止协程本身响应 cancel() 或抛出 CancelledError；它适用于必须完成的清理操作，而非暂停取消或重试逻辑。
asyncio.shield() 不会阻止任务被 cancel()，只防止协程体被取消
很多人误以为 asyncio.shield() 能“锁住”一个任务不让它被取消——其实它只是把协程对象包一层“不可取消的壳”，而底层协程本身仍可响应 cancel()。真正被 shield 的是 await 表达式执行过程：即使外层任务被取消，shield() 包裹的 await 仍会继续运行到完成（或抛出非取消类异常）。
典型错误现象：task.cancel() 后发现被 shield 的协程仍在跑，但日志里没报错、也没返回结果——这是因为外层 await 已被中断，而 shield 内部还在执行，但没人等它了。
- 使用场景：清理资源（如关闭连接）、写入日志、触发回调等必须完成的操作
- 不适用场景：想“暂停取消”或“重试被中断的操作”——shield 不提供重入或恢复能力
- 注意：
shield()返回的是一个Awaitable，不是Task；若需控制生命周期，得显式用create_task()包一层
shield() 内协程抛出 CancelledError 仍会穿透出来
asyncio.shield() 只屏蔽“外部取消请求对 await 点的中断”，不捕获或压制 CancelledError。如果被 shield 的协程自己调用了 raise asyncio.CancelledError，或者在内部 await 时被子协程传播上来（比如子任务被 cancel），这个异常仍会冒泡到 shield 外。
常见错误现象：调用 await asyncio.shield(some_coro())，结果还是收到 CancelledError，误以为 shield 失效。
立即学习“Python免费学习笔记（深入）”；
- 根本原因：shield 不等于 try/except CancelledError；它不介入异常传播链
- 若需彻底吞掉取消信号，必须在被 shield 的协程内部处理：用
try/except CancelledError捕获并做清理，再return或raise其他异常 - 性能影响极小，但滥用会导致逻辑混乱——比如在 shield 里做长时间轮询却不检查
asyncio.current_task().cancelled()，可能让整个事件循环卡住
与 create_task() + cancel() 配合时的典型陷阱
最易踩坑的是：先 task = asyncio.create_task(coro)，再 await asyncio.shield(task)。这看似“保护任务”，实则无效——因为 shield() 包裹的是 task 对象的 await 行为，而 task 本身已被调度执行；此时 cancel task，其内部协程仍会收到取消信号。
正确做法是 shield 协程调用本身，而不是已启动的 task：
await asyncio.shield(some_coro()) # ✅ 正确：shield 协程执行过程
task = asyncio.create_task(some_coro()) await asyncio.shield(task) # ❌ 无效：task 已运行，shield 只影响 await task 这一步
- 若真要 shield 一个已存在的 task，应改用
asyncio.shield(task._coro)（不推荐，属私有属性） - 更稳妥的方式：用
asyncio.create_task(asyncio.shield(some_coro()))，然后管理这个新 task - 注意：shield 后的 await 仍可被外层取消，只是被 shield 的部分不受影响——取消点只在外层 await 返回前
嵌套 shield 和 timeout 组合时的边界行为
asyncio.wait_for() 和 asyncio.shield() 套用时，容易产生“以为超时了，其实没停”的错觉。例如：await asyncio.wait_for(asyncio.shield(long_io()), timeout=1)，timeout 触发后外层 await 抛出 TimeoutError，但 long_io() 仍在后台跑。
这不是 bug，而是设计使然：shield 保证内部协程不因外层取消而中断，而 wait_for 的 timeout 正是通过 cancel 实现的。
- 若需真正中断 IO，不能依赖 shield + wait_for；应改用支持取消的底层 API（如
asyncio.timeout()上下文管理器 + 可取消的 read/write） - Python 3.11+ 推荐用
async with asyncio.timeout(1): await long_io()，它和 shield 不冲突，且能正确传播取消 - 兼容旧版本时，shield 应仅用于“无论如何都要做完”的收尾动作，而非主逻辑的超时控制
真正的难点不在怎么写 shield，而在于判断“哪段逻辑必须 shield”——它不是保险丝，而是单向阀门：只保执行完成，不保原子性、不保顺序、也不保不重复。用之前，先问一句：这段代码如果被并发 cancel 多次，还能安全执行完吗？
