asyncio.shield() 仅保护“await task”这一操作不被父级取消，不保护协程启动过程或内部后续await；误用await asyncio.shield(coro())会导致初始化阶段裸奔，且shield后任务可能成孤儿，需显式收尾。
asyncio.shield() 不是“让任务不被取消”，而是“让 await 这个动作不响应父级取消”——用错地方，它就完全失效。
shield 只保护 await 过程，不保护协程启动
最常见的误用是直接 await asyncio.shield(some_coro())。问题在于：some_coro() 在进入 shield() 之前就已经开始执行了，中间那段没被保护的初始化、首 await 点（比如 DNS 查询、连接建立）仍可能被外部 cancel 中断。
正确做法是先调度、再 shield：
- ✅
task = asyncio.create_task(fetch_data())→ 立即启动 - ✅
await asyncio.shield(task)→ 保护的是“等待 task 完成”这个行为 - ❌
await asyncio.shield(fetch_data())→ 启动过程裸奔，shield 来晚了
本质区别：前者 shield 的是已存在的 Task 对象的 await；后者 shield 的是刚构造出的协程对象，而 asyncio 会自动把它包装成 Task 并立刻调度——但这个“立刻”就是漏洞。
shield 被 cancel 后，任务还在跑，但你可能根本不知道
调用 shielded_task.cancel() 或外层任务被 cancel，只会让 await asyncio.shield(task) 抛出 CancelledError，而 task 本身仍在后台运行。如果之后没人等它、也不检查它状态，就会变成孤儿任务。
典型风险点：
- 数据库事务提交后没
await task，__aexit__不触发，连接没释放 - 日志写入协程被 shield 后超时退出，但日志文件句柄一直开着
- 在
try/finally里用了await asyncio.shield(task)，却忘了finally里await task或task.cancel()
必须显式收尾：哪怕只是 await task 等它自然结束，或 task.cancel() + await task 强制终止。
和 wait_for 组合时，shield 只挡取消，不挡超时
asyncio.wait_for(asyncio.shield(task), timeout=5) 是常见模式，但它只做一件事：5 秒后抛 TimeoutError，同时让 task 继续跑。这之后的逻辑你必须自己写清楚：
- 在
except asyncio.TimeoutError:块里，要决定是await task（等它完成关键操作），还是task.cancel()（确认可中断） - 不能只 catch
TimeoutError就返回，默认忽略task状态 -
CancelledError和TimeoutError是两类异常：前者来自 cancel()，后者来自 wait_for；处理方式完全不同
注意：wait_for 的 timeout 不等于资源安全时限——它不释放锁、不关闭连接，仅取消等待。真正清理必须靠 shield 内部协程自己处理，或靠外层显式 await。
shield 不压制 CancelledError，只屏蔽传播
如果被 shield 的协程内部主动 raise asyncio.CancelledError，或者它 await 的子任务被 cancel 导致异常上抛，CancelledError 依然会穿透 shield 出来。shield 不是 try/except，它不捕获异常。
所以，真正需要“保命”的逻辑（如写日志、关文件），必须在协程内部做防御：
- 用
try/finally包裹关键清理代码 - 或在
except asyncio.CancelledError:里做完清理再return或raise其他异常 - 别指望 shield 替你兜底——它只负责“不让 await 被打断”，不负责“让协程变健壮”
最容易被忽略的一点：shield 的保护边界非常窄，只作用于单次 await 表达式；一旦协程 resume 后再次 await 其他东西，那新的 await 点又暴露在外了。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
