asyncio.create_task()后任务被静默取消是因为未保存task对象导致gc回收时自动cancel；cpython 3.11+中__del__会触发警告“task was destroyed but it is pending!”。
asyncio.create_task() 后任务被静默取消的典型现象
你调用 asyncio.create_task() 启动一个协程，但没保存返回的 Task 对象，几秒后发现它根本没执行完就停了——这不是超时或异常，而是任务对象被 Python 的 GC 回收时自动调用 cancel() 导致的。CPython 3.11+ 中尤其明显，因为 Task 的 __del__ 方法会主动 cancel 自身并发出警告：Task was destroyed but it is pending!
为什么直接丢弃 create_task() 返回值是危险的
asyncio.create_task() 返回的是一个强引用的 Task 对象；一旦你没把它赋给变量、没放进列表、也没传给其他长期存活的对象，它就成了局部临时对象。事件循环虽然在调度它，但 Python 的 GC 不知道“这个对象正在被 event loop 引用”，只看 Python 层的引用计数/可达性。结果就是：函数返回后，Task 被回收 → __del__ 触发 → cancel() → 协程被中断。
- 常见于写法如：
asyncio.create_task(some_coro())单独一行，无赋值 - 也出现在类方法中：
self._task = None后又忘记重新赋值，导致旧Task失去引用 - 注意：
asyncio.ensure_future()行为相同，同样需要持有返回值
三种可靠持有 Task 引用的方式
核心原则：让 Task 对象至少被一个生命周期长于其自身运行时间的 Python 对象所引用。
- 显式绑定到实例属性：
self.background_task = asyncio.create_task(self.poll_loop())，并在类销毁前手动cancel()+await - 加入全局或模块级集合（谨慎）：
ACTIVE_TASKS.add(asyncio.create_task(...))，记得任务结束时.discard()，否则内存泄漏 - 用
asyncio.get_event_loop().create_task()不解决根本问题——它和create_task()返回的是同一类对象，仍需持有引用
不推荐用 asyncio.run_coroutine_threadsafe() 替代，它不返回 Task，且用于跨线程，场景不符。
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
如何验证任务是否真的被 GC 干掉
启动 Python 时加 -W error:Task was destroyed 参数，或在代码开头插入：
import warnings
warnings.filterwarnings("error", message="Task was destroyed but it is pending!")
这样一旦发生静默取消，立刻抛出 ResourceWarning（在严格模式下升级为异常），方便定位哪行漏存了 Task。
真正难处理的是那些“本该长期运行却意外退出”的后台任务——它们往往不报错，只悄悄停摆。盯住 Task 的生命周期，比调试协程逻辑本身还关键。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
