Toplevel 默认不阻塞主窗口，因其是非模态的；需配合 grab_set()、focus_set() 和 wait_window() 才能实现可控模态行为，否则主窗仍可交互或出现焦点/资源管理异常。
为什么直接 new Toplevel() 会卡住主窗口？
因为 Toplevel 默认不阻塞，但如果你没手动管理它的生命周期，主窗口可能被遮挡、失去焦点，甚至在子窗口关闭后残留引用导致资源泄漏。关键不是“弹出来”，而是“弹得可控、关得干净”。
常见错误现象：Toplevel 窗口一打开，主窗口就无法点击；关闭子窗后，root 仍被冻结；多次点击按钮反复创建新实例，内存里堆了一堆没销毁的 Toplevel。
- 每次调用前先检查是否已存在：用一个实例变量（如
self.dialog）缓存当前Toplevel，if self.dialog is None or not self.dialog.winfo_exists(): - 绑定
destroy事件而非quit：用dialog.protocol("WM_DELETE_WINDOW", lambda: self.close_dialog())，并在close_dialog()中设self.dialog = None - 不要在
Toplevel内调用mainloop()—— Tkinter 只需要一个主事件循环，子窗自动接入其中
如何让 Toplevel 表现得像模态对话框？
Tkinter 没有原生 show_modal()，但可以用 grab_set() + focus_set() + wait_window() 组合模拟。这三者缺一不可，否则用户仍能切回主窗操作。
典型使用场景：确认删除、输入密码、选择文件路径等需要强制用户响应的操作。
立即学习“Python免费学习笔记（深入）”；
-
dialog.grab_set()：捕获所有鼠标/键盘事件，阻止主窗交互 -
dialog.focus_set()：确保焦点落在子窗，避免按 Tab 键跳回主窗 -
dialog.wait_window()：阻塞当前函数执行，直到dialog被销毁（注意：不是dialog.mainloop()） - 必须在
grab_set()后立即调用focus_set()，否则 macOS 上可能失效
为什么 Toplevel 的位置和大小总不对？
Toplevel 初始化时尺寸为 1×1 像素，位置由系统决定；geometry() 必须在窗口完全映射后再调用，否则无效或偏移。尤其在多屏、高 DPI 或 Wayland 环境下更明显。
参数差异：geometry("400x300+100+100") 中的 +100+100 是相对于屏幕左上角的坐标，不是主窗；若想居中，得手动算：
dialog.update_idletasks()
width, height = 400, 300
x = (dialog.winfo_screenwidth() // 2) - (width // 2)
y = (dialog.winfo_screenheight() // 2) - (height // 2)
dialog.geometry(f"{width}x{height}+{x}+{y}")- 务必在
dialog创建后、grab_set()前调用update_idletasks()，否则winfo_screenwidth()返回 1 - 避免用
resizable(False, False)后再调geometry()—— 有些版本会忽略尺寸设置 - Linux/X11 下若窗口闪一下消失，大概率是
geometry()调太早，加个dialog.after(10, lambda: ...)延迟执行
如何安全地在 Toplevel 中获取用户输入并返回结果？
不能靠全局变量或闭包传值——线程不安全，且多个子窗并发时结果错乱。正确做法是把输入控件、确认逻辑和结果存储封装进 Toplevel 实例内部，并通过属性暴露结果。
性能影响不大，但结构混乱会导致后续扩展困难：比如加校验、支持取消、复用对话框逻辑等。
- 在子窗类里定义
self.result = None，点击“确定”时赋值（如self.result = entry.get().strip()），再调self.destroy() - 主窗调用处用
dialog.wait_window()阻塞后，直接读dialog.result - 如果用户点右上角 X 关闭，
result保持None，主逻辑据此判断是否取消操作 - 避免在子窗里直接修改主窗变量（如
root.data = ...），破坏封装性
复杂点在于状态同步：Toplevel 生命周期短，但它的回调函数（如按钮命令）可能引用外部对象，容易造成循环引用。最容易被忽略的是没显式断开 StringVar 或 trace 回调，在 destroy() 前要手动 trace_vdelete。
