直接调用task.cancel()是唯一可靠取消方式，但必须await task或检查task.exception()确认结果，否则取消信号可能被忽略；协程需主动响应，避免同步阻塞调用和错误异常捕获。
asyncio.create_task() 后怎么安全取消？
直接调用 task.cancel() 是唯一可靠方式，但必须配合 await task 或 task.exception() 检查结果，否则取消信号可能被忽略。协程内部若没做异常处理（比如没包在 try/except CancelledError 里），取消后会静默失败或卡住。
常见错误是调用 task.cancel() 就以为完事了——其实只是“发了个信号”，协程得自己响应。如果它正在执行 CPU 密集型操作、阻塞 IO 或没写 await 点，就根本收不到。
- 务必在取消后
await task，否则无法确认是否已退出 - 若不想等，可用
asyncio.wait([task], timeout=0.1)做有限等待 - 取消后检查
task.done()和task.cancelled()，别只看返回值
为什么 await asyncio.sleep() 能被取消，而 time.sleep() 不行？
asyncio.sleep() 是协作式暂停，底层会检查事件循环是否收到取消请求；time.sleep() 是同步阻塞调用，会直接挂起整个线程，事件循环停摆，自然无法响应取消。
这是最常踩的坑：在协程里混用同步阻塞函数（如 requests.get()、json.load()、subprocess.run()）。它们会让协程“假死”，取消失效。
- 替换
requests→aiohttp或httpx.AsyncClient - 替换
time.sleep()→await asyncio.sleep() - 替换
subprocess.run()→await asyncio.create_subprocess_exec()
如何避免 cancel() 被协程内部吞掉？
协程中捕获了 Exception 却没重新抛出 CancelledError，会导致取消被静默吃掉。Python 3.8+ 中 CancelledError 是 BaseException 子类，不继承自 Exception，所以 except Exception: 根本捕不到它。
python-docx Skill功能概述python-docx Skill是一项面向实际任务的技能，主要用于本Skill提供使用python-docx生成专业Word文档的标准方法和最佳实践；生成安全服务方案文档；核心要点生成技术架构设计文档；生成任何需要专业排版的Word文档；核心库 : python-docx；使用与执行辅助库 : docx.shared , docx.enum , docx.oxml.ns；标准代码模板；1. 文档初始化；2. 字体设置（必须！它将相关步骤、工具调用和结果整理方式集
典型反模式：
try:
await something()
except Exception: # ← 这里拦不住 CancelledError
log("error")
正确写法是显式处理或让其向上冒泡：
- 不捕获
CancelledError，让它自然传播（推荐） - 若必须清理，用
except asyncio.CancelledError:单独处理，最后raise - 避免
except:或except BaseException:（除非你真要拦截所有）
cancel() 失效时，还有没有兜底手段？
没有。asyncio 的取消机制完全依赖协程主动协作，不存在强制终止。所谓“强制”只能靠外部进程 kill、线程 interrupt（不安全）、或把耗时逻辑移到子进程里再杀掉进程——但这已经脱离 asyncio 语义了。
真正能做的只有两件事：一是确保协程足够“轻量可中断”，比如拆成多个 await 步骤；二是对不可控的第三方同步调用，用 loop.run_in_executor() 包裹，并接受它无法被 asyncio 取消的事实（executor 任务需自行管理超时或中断）。
最容易被忽略的是：取消一个刚创建还没调度的 task，task.cancel() 会立即返回 True，但 task.done() 仍为 False，直到下一轮事件循环才真正标记为 done。别在 cancel 后立刻 assert done。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
