CancelledError是协程取消的控制流信号而非错误，需显式捕获并配合finally清理；它继承自BaseException，不能用except Exception捕获，必须写except asyncio.CancelledError:。
Python异步任务取消时抛出 CancelledError，不是程序出错，而是 asyncio 的控制流机制在起作用——它本质是协程被中断的信号，不是需要“修复”的异常。
CancelledError 为什么不能用 except Exception 捕获
CancelledError 从 Python 3.8 起继承自 BaseException，和 KeyboardInterrupt、SystemExit 同级，完全绕过 except Exception: 的拦截范围。
- 常见错误现象：写
except Exception:后发现任务被取消时没进 except 块，日志直接崩出未捕获异常 - 正确做法必须显式写
except asyncio.CancelledError:，别偷懒缩成except BaseException:（会吞掉真正致命的崩溃） - 第三方库（如 aiohttp）有时会把
CancelledError转成其他异常再抛，得查它文档确认行为
task.cancel() 后 await task 为什么还会报 CancelledError
调用 task.cancel() 只是给任务打上“待取消”标记，不终止执行；真正抛异常要等到下一次 await 点（比如 await task 或协程内部下一个 await 表达式）。
- 常见错误：cancel 之后没
await task，就以为任务结束了，结果资源泄漏、状态错乱 - 推荐写法：
try: await task except asyncio.CancelledError: pass—— 显式吸收信号，避免向上冒泡 - 若需等待清理完成，应在
except asyncio.CancelledError:块里做同步操作，或用asyncio.create_task()+asyncio.shield()启动异步收尾
finally 和 async with 在取消时是否可靠
finally 块和 async with 的 __aexit__ 是目前最可靠的清理入口，但有前提条件：
python-docx Skill功能概述python-docx Skill是一项面向实际任务的技能，主要用于本Skill提供使用python-docx生成专业Word文档的标准方法和最佳实践；生成安全服务方案文档；核心要点生成技术架构设计文档；生成任何需要专业排版的Word文档；核心库 : python-docx；使用与执行辅助库 : docx.shared , docx.enum , docx.oxml.ns；标准代码模板；1. 文档初始化；2. 字体设置（必须！它将相关步骤、工具调用和结果整理方式集
立即学习“Python免费学习笔记（深入）”；
- 它们确实比
except CancelledError更早触发（尤其当取消发生在await中间时），但前提是协程能走到那个位置 - 不要在
finally里再await可取消协程（比如await conn.close()），否则可能再次抛CancelledError中断清理 - 若必须
await，应加try/except asyncio.CancelledError并确保最终状态一致（如设conn._closed = True防止重复 close） - 绝对不要依赖
__del__或弱引用回调——它们不保证执行时机，取消时大概率不触发
纯同步阻塞（如 time.sleep、requests.get）为什么无法响应取消
asyncio 的取消信号只能在事件循环调度点（即 await）生效；纯同步阻塞会卡死整个 loop，取消信号根本进不来。
- time.sleep(10) → 必须换成
await asyncio.sleep(10) - requests.get() → 必须换成
aiohttp.ClientSession().get()或httpx.AsyncClient().get() - 无法改写的 sync 函数，可用
loop.run_in_executor()包装，但注意：线程内取消不可靠，只能靠超时或协作标志位退出 - 若非用
requests不可，至少加上timeout=参数，避免无限 hang
真正难处理的不是 CancelledError 本身，而是那些没有 await 点的长循环、没做取消适配的第三方 sync 调用、以及在 finally 里又 await 了另一个可能被取消的协程——这些地方最容易漏掉清理或引发二次异常。
