应复用Toplevel窗口：首次创建并保存引用，关闭时wm_withdraw()隐藏而非destroy()，后续用wm_deiconify()唤醒；每次调用前须isinstance()和winfo_exists()双重校验有效性，避免TclError。
用 top_level 的 wm_withdraw() 和 wm_deiconify() 控制窗口显隐
直接销毁窗口再重建，容易丢失状态、触发闪烁、甚至引发 TclError: invalid command name。更稳妥的做法是复用已有窗口：首次打开时创建 Toplevel 实例并保存引用；后续点击只调用 wm_deiconify() 激活它，而非新建。
关键点在于必须在窗口关闭（WM_DELETE_WINDOW）时改用 wm_withdraw() 隐藏而非 destroy()，否则引用失效，下次无法唤醒：
def open_settings():
global settings_window
if settings_window is None:
settings_window = Toplevel(root)
settings_window.title("设置")
settings_window.protocol("WM_DELETE_WINDOW", lambda: settings_window.wm_withdraw())
# …… 添加控件
else:
settings_window.wm_deiconify()
settings_window.lift()
settings_window.focus_force()
-
wm_deiconify()能恢复被最小化或隐藏的窗口，lift()确保它浮在最前，focus_force()强制获取输入焦点 - 不要用
settings_window.destroy()响应关闭事件——这会让settings_window变成无效对象，下次调用wm_deiconify()会报错RuntimeError: main window is not in normal state - 如果窗口含
Entry或Text等控件，隐藏/唤醒不会清空内容，状态自然保留
用 isinstance() + winfo_exists() 双重校验窗口有效性
仅靠全局变量判断是否为 None 不够安全：用户可能手动关闭窗口（绕过 protocol），导致变量仍指向已销毁对象，后续调用 wm_deiconify() 报 TclError: bad window path name。
必须增加运行时存在性检查：
立即学习“Python免费学习笔记（深入）”；
if settings_window is not None and settings_window.winfo_exists():
settings_window.wm_deiconify()
# ……
else:
settings_window = Toplevel(root)
# ……
-
winfo_exists()返回1表示窗口仍由 Tk 管理，返回0表示已被销毁（无论是否通过destroy()或系统关闭） - 不能只依赖
isinstance(settings_window, Toplevel)—— 销毁后变量仍为Toplevel类型，但已无有效底层窗口句柄 - 这个检查要放在每次打开逻辑的开头，尤其在多线程或绑定快捷键场景下必不可少
避免在 __init__ 中直接创建子窗口实例
把 Toplevel 创建写死在类初始化里，会导致每次实例化主界面就弹出子窗口，违背“按需打开”原则，也造成资源浪费。
- 子窗口应延迟创建（lazy init）：只在用户触发动作（如点击菜单项）时才 new 出来
- 全局变量（如
settings_window）初始值设为None，而非Toplevel(root) - 若使用面向对象封装，把子窗口引用作为实例属性（
self.settings_window = None），而非类属性，防止多个主窗口实例互相干扰
注意 grab_set() 和模态行为对多窗口的影响
如果子窗口调用了 grab_set()（变成模态对话框），它会独占输入焦点，此时用户无法切换回主窗口操作——但这和“防重复打开”无关，反而是设计意图。真正要警惕的是误用 grab_set() 后又试图用 wm_deiconify() 唤醒另一个已存在的模态窗口，Tkinter 会静默失败或抛异常。
- 非模态窗口（默认）适合设置页、日志面板等需常驻+可切换的场景，适用本文方案
- 模态窗口（如确认对话框）本就不该复用，每次应新建+
grab_set()+wait_window()，用完即弃 - 切勿对已
grab_set()的窗口再次调用wm_deiconify()并期望它脱离模态——Tkinter 不支持动态解除 grab
核心难点不在逻辑本身，而在于 Tkinter 对窗口生命周期的管理非常隐式：销毁后引用不自动置空、隐藏与销毁状态混同、错误提示模糊。务必坚持「存在性检查 + 隐藏代替销毁 + 延迟创建」三原则，少一步都可能在特定操作序列下崩溃。
