asyncio.create_task启动的任务若无强引用会被GC回收而静默消失；需显式保存引用、用task.cancel()配合await处理取消、避免atexit依赖，应由框架shutdown事件统一管理生命周期。
任务启动后就“消失”了？asyncio.create_task 不等于后台常驻
Python 里用 asyncio.create_task 启动协程，不加管控的话，任务一旦被垃圾回收或事件循环结束，就会静默退出——不是挂起，是真没了。常见现象：Flask/FastAPI 启动后调用一次异步任务，之后再无日志、无状态更新、无错误提示。
关键原因：create_task 返回的 Task 对象如果没被强引用（比如没存进全局列表、没绑定到类实例），Python 的 GC 可能在下一轮循环中直接清理它。
- 必须显式保存对
Task的引用，例如：self.background_task = asyncio.create_task(...) - Web 框架中避免在请求作用域内创建长期任务（如
request回调里直接create_task），任务可能随请求上下文销毁而丢失 - 调试时可定期检查
asyncio.all_tasks()，确认目标任务是否仍在运行列表中
怎么安全地停掉一个正在跑的 asyncio.Task？
直接 task.cancel() 是标准做法，但多数人忽略两件事：协程未必响应取消，以及取消后未处理的异常会“掉进黑洞”。典型错误现象：task.cancel() 调了，task.done() 立刻返回 True，但实际逻辑还在跑（比如没写 await asyncio.sleep() 或没检查 task.cancelled()）。
-
cancel()只是抛出CancelledError，协程需在可中断点（如await表达式）才能真正退出；纯 CPU 循环不会被中断 - 务必 await 任务完成：
await task或await asyncio.wait_for(task, timeout=...)，否则取消信号可能被吞掉 - 若任务已结束，再次
cancel()无副作用；但若想确保资源释放，建议统一用try/except CancelledError做清理
用 threading.Thread 跑后台任务更稳？小心 GIL 和生命周期错位
有人觉得线程“看得见摸得着”，比协程可控。但 Python 的 threading.Thread 在 Web 应用里容易引发更隐蔽的问题：主线程退出时子线程被强制终止（尤其用 daemon=False 且没 join），或者因 GIL 导致 CPU 密集型任务卡住整个事件循环。
立即学习“Python免费学习笔记（深入）”；
- 设为守护线程（
daemon=True）能避免阻塞进程退出，但意味着主线程一关，后台线程立刻被杀，无法做 graceful shutdown - 非守护线程必须显式
join()，但 Web 服务通常没有明确“关闭时刻”，容易漏掉或死等 - 若任务含 I/O（如 HTTP 请求、数据库查询），用线程反而增加调度开销；纯异步栈（aiohttp + asyncpg）才是更轻量的选择
atexit.register 能兜底清理吗？别信
很多人想靠 atexit.register 来统一 cancel 所有后台任务，听起来很稳妥。但实际中，这个钩子只在 Python 解释器正常退出时触发，遇到 SIGKILL、容器 OOM kill、k8s liveness probe 失败重启等情况，根本不会执行。
-
atexit不适用于生产级生命周期管理，仅适合开发调试阶段的辅助清理 - 真正的 shutdown 流程应由框架接管：FastAPI 提供
@app.on_event("shutdown")，Starlette 有on_shutdown列表，ASGI server（如 Uvicorn）也支持自定义 lifespan 协议 - 所有后台任务的引用必须集中管理（比如存在一个
set或dict中），并在 shutdown 回调里统一 cancel + await
最麻烦的不是启动或停止，而是任务中途崩溃又没被监听——asyncio.create_task 默认吃掉未处理异常，连 sys.excepthook 都捕获不到。真要管住生命周期，得从任务创建那一刻就决定谁负责引用、谁负责取消、谁负责重试、谁负责记录状态。
