cancellederror是协程取消的控制流信号而非错误，需显式捕获并配合finally清理；它不继承exception，须单独处理；task.cancel()仅标记状态，await时才触发；asyncio.run()会静默吞掉未处理的cancellederror。
协程被取消时为什么直接抛 CancelledError 而不是静默失败
因为 CancelledError 是 Python 协程取消机制的信号载体，不是异常“错误”，而是控制流的一部分。它由 asyncio.Task.cancel() 触发，用于中断正在运行或等待中的协程。不捕获它，协程就终止；捕获它，你才有机会做清理。
常见错误现象：CancelledError 没被处理，导致日志里突然出现未捕获异常、资源没释放（比如文件句柄、数据库连接）、或者父任务误判子任务是“出错了”而不是“被取消了”。
- 必须在
try/except中显式捕获CancelledError，不能只写except Exception:—— 它不继承自Exception，而是继承自BaseException - 捕获后通常应立即重新抛出（
raise），除非你确定要吞掉取消信号（极少见） - 清理逻辑（如
close()、disconnect()）必须放在finally块里，不能只靠except
asyncio.wait_for 里 CancelledError 的来源和归属问题
asyncio.wait_for 在超时时会取消内部任务，此时抛出的 CancelledError 属于被等待的那个协程，不是 wait_for 自己抛的。很多人误以为 catch 住 asyncio.TimeoutError 就够了，结果漏掉了底层协程实际已被取消的事实。
使用场景：调用一个可能卡住的网络请求，设了 5 秒超时，但请求协程本身没做取消适配，导致 socket 连接一直挂着。
立即学习“Python免费学习笔记（深入）”；
Sooolink企业信使是新一代的企业协同工作系统，以及时沟通为基础，将企业业务流程合理的穿插其中；给企业业务处理融入及时的消息，信息通知。让工作变得更加及时，有效，提高生产效率。目前暂时只发布了 windows 版本。
-
asyncio.TimeoutError和CancelledError可能同时存在：前者是wait_for抛的，后者是它取消子任务时子任务自己抛的 - 若子协程里没处理
CancelledError，整个调用栈会崩，TimeoutError反而可能被掩盖 - 推荐写法：在被
wait_for包裹的协程内部，用try/except CancelledError+finally做清理，而不是只依赖外层超时处理
Task.cancel() 后 await task 为什么会再次触发 CancelledError
调用 task.cancel() 只是“标记”任务为取消状态，并不会立刻中断执行。真正抛 CancelledError 是在下一次 await（比如 await task 或协程内下个 await 表达式）时发生的。所以如果你 cancel 之后又 await task，就会看到异常——这不是重复抛，而是取消信号终于落地了。
性能影响：频繁 cancel + await 未完成的 task，会导致事件循环反复调度、异常对象创建，间接拖慢响应。
- cancel 之后别盲目
await task，先用task.done()判断是否已结束 - 如果只是想“确保取消”，用
await asyncio.shield(task)不合适；正确做法是if not task.done(): await task，并在 task 内部处理好CancelledError - 注意
asyncio.create_task()创建的任务默认不可取消（除非你传name=...并保留引用），cancel 失败也不会报错，容易误以为生效了
asyncio.run() 退出时 CancelledError 被吞掉的隐性行为
asyncio.run() 在主协程返回或异常退出后，会自动 cancel 所有还在 pending 的 task，并静默忽略它们的 CancelledError。这很方便，但也掩盖了本该被观察到的资源泄漏或未完成清理。
容易踩的坑：你在 main 里启动了一个后台心跳协程，main 结束后心跳 task 被 cancel，但它没做任何清理（比如关 socket），而你完全不知道——因为 CancelledError 被 run() 吞了，日志里什么都没有。
- 开发阶段建议改用
asyncio.get_event_loop().run_until_complete(main())，这样未处理的CancelledError会暴露出来 - 所有长期运行的 task 都应自带取消处理逻辑，不能依赖
asyncio.run()的兜底 - 可以用
asyncio.all_tasks()+loop.set_exception_handler()主动监控未处理的取消异常
最常被忽略的一点：取消不是“停止”，而是“协作式中断”。协程自己得愿意停下来，并且知道怎么收摊——否则 CancelledError 就只是个没人认领的通知。
