最常见原因是绑定后未调用mainloop()或窗口对象已销毁；必须手动控制窗口生命周期，如用iconify()隐藏或messagebox确认后再destroy()。
为什么 protocol('WM_DELETE_WINDOW') 不生效
最常见原因是：绑定之后没调用 mainloop()，或者在 mainloop() 启动前就退出了；也可能是你绑定了但没显式调用 withdraw()、iconify() 或 destroy()，导致 Tkinter 认为窗口仍应“正常关闭”。Tkinter 不会自动阻止关闭，它只负责把事件转给你——拦不拦、怎么拦，全靠你自己在回调里决定。
- 确保绑定发生在
mainloop()之前，且窗口对象（如root）还活着 - 回调函数里**必须手动控制窗口生命周期**，比如不调用
destroy()就不会真关掉 - 如果用了
Toplevel，要对那个实例调用protocol，不是对root
怎么写一个真正能拦截关闭的回调函数
核心就一条：别让回调结束时窗口自己销毁。Tkinter 默认行为是触发 destroy()，所以你要覆盖它。典型做法是隐藏窗口或弹确认框，再由用户决定是否真关。
- 想“最小化代替关闭”：在回调里调用
root.iconify()，然后return - 想“弹窗确认”：用
messagebox.askokcancel()，返回True再调root.destroy()，否则什么也不做 - 绝对不要在回调里写
root.destroy()无条件执行——那等于没拦截
def on_closing():
if messagebox.askokcancel("退出", "确定要退出吗？"):
root.destroy()
root.protocol("WM_DELETE_WINDOW", on_closing)
WM_DELETE_WINDOW 和 bind('<destroy>')</destroy> 的区别
protocol('WM_DELETE_WINDOW') 是主动拦截系统级关闭请求（点 X、Alt+F4、任务管理器结束等），而 bind('<destroy>')</destroy> 是被动响应——窗口**已经销毁完毕后**才触发，此时 root 可能已不可用，不能用来阻止关闭。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
-
protocol是唯一能干预关闭流程的入口；<destroy></destroy>只适合清理资源、保存状态 - 如果你同时用了两者，
protocol回调先执行，<destroy></destroy>在窗口真销毁后才执行（甚至可能不执行，比如你只iconify()了） - 注意拼写：
WM_DELETE_WINDOW全大写，少下划线或大小写错误都会静默失败
多窗口场景下容易漏掉的绑定点
每个独立窗口（Tk 或 Toplevel 实例）都要单独绑定。主窗口 root 绑了，不代表子窗口也受控；子窗口关掉也不会触发主窗口的 protocol 回调。
立即学习“Python免费学习笔记（深入）”；
- 对每个
Toplevel创建后立即调用它的protocol()，别复用主窗口的回调函数名而不改逻辑 - 如果子窗口依赖主窗口状态，回调里检查
root.winfo_exists()，避免主窗口已销毁时子窗口还试图访问它 - 多个窗口共用同一套关闭逻辑？把回调写成带参数的函数，或用
lambda w=window: on_closing(w)捕获当前窗口引用
