主窗口关闭后进程未退出，首要排查未销毁的Toplevel子窗口和非守护线程；root.destroy()不递归销毁子窗口，需手动维护列表并统一.destroy()，配合root.quit()退出mainloop，同时确保线程设为daemon=True。
主窗口关了但进程还在，先查有没有漏掉的 Toplevel 窗口
点 × 关掉主窗口后任务管理器里 Python 进程还挂着，第一件事不是改 protocol，而是确认有没有没销毁的 Toplevel 实例。Tkinter 的 root.destroy() 不会递归销毁子窗口，只要一个 Toplevel 对象还活着，mainloop() 就不会真正退出。
常见错误现象包括：
- 界面消失但进程 CPU 占用不为 0
- 反复打开/关闭子窗口后内存持续上涨
- 打包成 exe 后关掉所有窗口，进程残留数分钟才消失
调试时加一句：print([w for w in root.children.values() if isinstance(w, tk.Toplevel)])，能快速看出是否还有存活的 Toplevel；更稳妥的做法是自己维护一个 list 或 set，每次创建 Toplevel 就 append() 进去，关闭前统一调用 .destroy()。
root.quit() 和 root.destroy() 必须配合用，不能只选一个
root.quit() 只是退出 mainloop()，不销毁任何窗口对象；root.destroy() 销毁窗口但不保证 mainloop() 退出——尤其当有嵌套 mainloop() 或子窗口自己调过 mainloop() 时。
立即学习“Python免费学习笔记（深入）”；
安全组合是：显式销毁所有 Toplevel → root.destroy() → root.quit()。
注意：
- 模态子窗口（用了
grab_set()）通常只需root.destroy()，前提是没手动在子窗口里调mainloop() -
sys.exit(0)是硬退出，绕过 Tkinter 生命周期，可能导致文件句柄、socket 等资源没释放 - 混用
root.quit()和sys.exit()容易触发TclError: can't invoke "destroy" command
后台线程没设成守护线程，关窗后照跑
很多“假退出”根本不是窗口问题，而是非守护线程卡着进程。主线程结束时，daemon=False 的线程会阻止整个进程终止。
正确做法是：
- 所有后台线程必须在
start()前设thread.daemon = True（或用threading.Thread(..., daemon=True)） - 不能靠
thread.join()等待线程结束——这会让 GUI 卡住，违背异步初衷 - 如果线程里有阻塞操作（如网络请求、
time.sleep()），需配合threading.Event提供中断信号
验证方法：print(threading.active_count(), threading.enumerate())，关窗后应只剩主线程和几个 daemon 线程（如 pydevd 调试线程）。
第三方库资源没释放，也会拖住进程
matplotlib、数据库连接、串口通信等外部资源若未显式关闭，可能让进程僵在退出阶段。
典型泄漏点：
-
plt.figure()后没配plt.close('all')，图形对象被全局引用持有着 - sqlite 连接没调
.close()，或游标没回收，lsof -p $PID | wc -l显示 open files 异常多 - 使用
threading.Timer或root.after()创建的定时器没取消，回调还在排队
关键原则：谁创建，谁负责清理。窗口关闭逻辑里要补上对应资源的释放调用，而不是依赖 GC。
最常被忽略的是：Toplevel 窗口一旦调过 withdraw() 或 deiconify()，就容易脱离 root 的生命周期管理，变成“幽灵窗口”——它不显示，但对象仍存在，且不会被 winfo_children() 捕获。这种必须靠你自己维护的引用列表来追踪和销毁。
