wm_delete_window不能捕获最小化/最大化，因为它仅响应关闭类事件；最小化/最大化不销毁窗口，只改变状态；tkinter无wm_minimize协议，可用和事件近似监听。
为什么 WM_DELETE_WINDOW 不能捕获最小化/最大化
因为最小化和最大化不触发窗口销毁，它们只是改变窗口状态。Tkinter 的 protocol 机制（如 WM_DELETE_WINDOW）只响应关闭类事件，对状态变更完全无感。你绑 protocol("WM_MINIMIZE", ...) 会直接报错 —— 这个协议根本不存在。
bind("<map>")</map> 和 bind("<unmap>")</unmap> 是实际可用的信号
这两个虚拟事件在窗口「显示」或「隐藏」时触发，而最小化会让主窗口进入 Unmap 状态（注意：不是 destroy，也不是 withdraw），恢复时触发 Map。但要注意：
-
<unmap></unmap>不仅在最小化时触发，也会在窗口被遮挡、切换到其他应用、甚至调用withdraw()时触发 -
<map></map>在窗口从隐藏/最小化恢复、或首次显示时都触发，无法单靠它区分“刚启动”和“从最小化恢复” - Windows 下行为最稳定；Linux（尤其 Wayland）可能延迟或漏发；macOS 对最小化的
Unmap支持较弱
简单验证示例：
import tkinter as tk
root = tk.Tk()
root.title("Minimize Test")
def on_map(event):
print("窗口已映射（可能：启动 / 从最小化恢复 / 从隐藏显示）")
def on_unmap(event):
print("窗口已取消映射（可能：最小化 / 切换到其他应用 / 被遮挡）")
root.bind("<map>", on_map)
root.bind("<unmap>", on_unmap)
root.mainloop()
</unmap></map>
如何区分最小化和其他 <unmap></unmap> 场景
纯 Tkinter 没有直接获取窗口当前状态（如是否最小化）的 API，但可以结合 winfo_viewable() 和平台特性做近似判断：
-
root.winfo_viewable()返回False表示窗口不可见（最小化或被隐藏），但无法确认具体原因 - Windows 下可调用
ctypes查询窗口样式：GetWindowLong(hwnd, GWL_STYLE)+WS_MINIMIZE标志位，但跨平台维护成本高 - 更实用的做法是：记录上一次可见状态，配合
<focusin></focusin>和<focusout></focusout>做辅助判断 —— 最小化通常伴随FocusOut，且之后不会立刻有FocusIn - 如果业务只要“用户离开窗口”，
<unmap></unmap>+<focusout></focusout>双触发比单靠一个更可靠
不要依赖 root.state("iconic") 实时轮询
有人尝试用定时器反复调用 root.state() 检查是否为 "iconic"，这既低效又不准：
-
root.state()在非 Windows 平台返回值不稳定（macOS 常返回"normal"即使窗口已最小化） - 轮询间隔太短浪费 CPU，太长导致延迟；Tkinter 主循环本身不保证定时精度
- 某些桌面环境（如 GNOME）根本不向 X11 应用暴露最小化状态
- 真正需要精确状态时，应考虑改用
PyQt5/6或customtkinter，它们封装了底层 WM 事件
最小化/最大化的监听本质是“尽力而为”，不是“精确控制”。多数场景下，用 <unmap></unmap> 触发暂停后台任务、用 <map></map> 触发刷新 UI，已经够用。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
