asyncio.CancelledError 频繁出现是因取消信号默认穿透传播：父任务取消会立即中断所有 await 子协程，即使其正执行 I/O 或调用非适配库；这是设计使然，确保超时与中断可靠性，而非 bug。
asyncio.CancelledError 为什么总在不该出现的地方冒出来
因为 Python 的任务取消默认是“穿透式”传播的——只要父任务被取消，所有 await 的子协程都会收到 CancelledError，哪怕它内部正执行 I/O 或调用第三方库。这不是 bug，是 asyncio 的设计契约：取消信号必须可传递，否则无法实现可靠超时和中断。
常见错误现象：CancelledError 在 await asyncio.sleep(10) 中间抛出，但调用栈里根本没看到你主动调用 task.cancel()；或者你在 try/except CancelledError 里做了清理，结果发现子协程里的数据库连接没关掉——因为异常在进入子协程前就被捕获并吞掉了。
- 关键判断点：检查是否用了
asyncio.shield()包裹关键子协程，它能阻止取消传播，但也会让超时逻辑失效 - 如果子协程本身不处理取消（比如调用的是纯同步函数或未适配 asyncio 的 SDK），建议用
loop.run_in_executor()包一层，再在外层做 cancel 控制 -
asyncio.wait_for()默认会传播取消；若想隔离，得配合asyncio.create_task()+ 手动cancel()+asyncio.gather(..., return_exceptions=True)
如何让某个 await 表达式不响应父任务取消
不是“屏蔽取消”，而是“延迟响应”或“移交控制权”。直接吞掉 CancelledError 是危险的，会导致父任务永远等不到结束。
使用场景：你启动了一个后台心跳协程，它需要持续运行，即使发起它的 HTTP 请求已超时关闭。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 用
asyncio.shield()最简单，但它会让该协程完全免疫取消——包括你后续手动调用task.cancel()也无效 - 更可控的做法是用
asyncio.create_task()启动独立任务，并在父协程中通过asyncio.current_task().cancelled()主动轮询状态，决定是否继续 await 它 - 避免对
asyncio.to_thread()或loop.run_in_executor()返回的Awaitable直接shield，线程池任务取消不保证生效，可能造成资源泄漏
asyncio.gather() 和 asyncio.wait() 在取消传播上的行为差异
两者都用于并发等待多个协程，但对取消的反应完全不同：gather 是“全有或全无”，wait 是“按需响应”。这个差异直接影响你能否精准控制哪部分被取消。
常见错误现象：用 await asyncio.gather(a(), b(), c())，其中 b() 耗时长，你取消整个 gather，结果 a() 和 c() 的清理逻辑没执行——因为 gather 一收到取消就立刻中断所有子任务，不等它们完成 finally 块。
-
asyncio.gather(..., return_exceptions=True)只影响异常是否抛出，不改变取消传播时机 -
asyncio.wait()配合return_when=asyncio.FIRST_COMPLETED可以实现“只要一个完成就停”，但剩余未完成任务仍处于 pending 状态，需手动 cancel 并 await 其 cleanup - 若要确保每个子任务都有机会执行 finally，别用
gather，改用asyncio.create_task()分别启动，再用asyncio.wait()等待完成集合
第三方异步库（如 httpx、aiomysql）对取消信号的兼容性陷阱
很多库声称“支持 asyncio”，但实际只在顶层协程响应取消，底层 socket 或连接池操作仍可能阻塞。这不是它们的错，而是 Python 异步生态里普遍存在的“取消盲区”。
使用场景：你用 httpx.AsyncClient 发起请求，设置了 timeout=5.0，但网络卡死时，任务取消后仍卡在 await response.aread() 上。
- 检查库文档是否明确写了“cancellation-aware”；例如
httpx从 v0.23 开始才真正支持中断读取流，旧版本只能靠 timeout 触发，不能靠 task.cancel() - 不要依赖
async with自动 cleanup：有些库的__aexit__不检查exc_type is CancelledError，导致连接泄露 - 最稳妥的方式是给关键 I/O 加上
asyncio.wait_for(..., timeout=...)，而不是依赖库自身的 timeout 参数——前者能触发真正的协程级中断
取消传播不是开关，而是一条链路。每个 await 点都可能是断点，也可能是盲点。真正难的不是写 shield 或 gather，而是判断哪个环节该透传、哪个该拦截、哪个其实拦不住。
