Tkinter关闭时asyncio任务报错，是因为窗口销毁后事件循环被关闭，而未完成的异步任务仍尝试访问已关闭的loop，导致RuntimeError或CancelledError；必须在wm_delete_window协议中主动取消并等待所有任务结束，再调用root.destroy()。

为什么Tkinter关闭时asyncio任务会报错？

Tkinter窗口一旦关闭，mainloop()就会退出。

问题通常出在这里：如果你曾在事件回调里，比如按钮点击时，用asyncio.create_task()启动了异步任务，这些任务大概率还没跑完。

到了关闭阶段，Python解释器已经开始销毁全局对象，事件循环也会被一起清理。此时，没结束的task还想继续await，或者去访问已经被回收的loop，就容易抛出RuntimeError: Event loop is closed或CancelledError。

更麻烦的是，这类异常通常不会被打印出来。因为tkinter这时已经不再处理回调，结果就是程序看起来像直接卡住，甚至崩掉。

必须在root.protocol("wm_delete_window", ...)里做任务清理

不能只写root.destroy()就结束。

关键做法是在用户点击“×”时，主动取消所有活跃的asyncio任务，并等待它们结束。否则，任务会在后台继续运行，直到访问已关闭的loop。

• 先调用asyncio.all_tasks()拿到当前所有task，排除asyncio.current_task()（即关闭逻辑本身）
• 对每个task调用task.cancel()，然后await asyncio.gather(*tasks, return_exceptions=True)确保它们真正退出
• 最后再调用root.destroy()，而不是root.quit()——后者只退出事件循环，不保证资源释放

asyncio.run()和Tkinter共存时的事件循环冲突

如果在Tkinter里直接用asyncio.run()去启动协程，马上就会撞上RuntimeError: asyncio.run() cannot be called from a running event loop。

原因很简单：Tkinter的mainloop()本身就是一个事件循环，和asyncio这套机制是互相冲突的。

• 正确做法是：用asyncio.get_event_loop()复用Tkinter线程的loop，而不是新建一个
• 如果loop未启动，需手动调用loop.run_until_complete()或loop.create_task()，但绝不能在mainloop()运行中再调asyncio.run()
• 更稳妥的方式是用root.after(1, lambda: loop.call_soon_threadsafe(...))把协程调度进Tkinter主线程的loop里

容易被忽略的CancelledError二次传播问题

有些人会在task里捕获asyncio.CancelledError后做清理，但没有raise。

这样会导致取消信号被吞掉，task状态卡在“cancelled but not done”，后续await task可能会永远挂起。

• 必须在except asyncio.CancelledError:块末尾加raise，否则取消失败
• 不要用宽泛的except Exception:包裹await，它会意外拦截CancelledError
• 日志记录可以用logging.info("Task cancelled")，但别用messagebox.showinfo()——GUI组件在destroy后调用会崩溃

退出阶段的核心顺序

Tkinter与asyncio混合使用时，退出阶段不是“关窗就完事”。

真正要协调的是两个生命周期：窗口销毁、任务取消、事件循环清理。三者顺序只要错一环，就会留下静默异常或残留进程。

《夸克》非常好用的免费AI浏览器

下载APP查看