Tkinter多窗口间直接用全局变量传数据易出问题，因Toplevel作用域不共享、销毁后变量重置、缺乏数据回传机制、竞态风险及无法感知更新时机；推荐用wait_window()同步获取或自定义事件异步通信。
为什么直接用全局变量传数据在Tkinter多窗口里容易出问题
Tkinter的窗口对象（Toplevel）默认不共享作用域，即使你在主窗口定义了全局变量，子窗口修改后主窗口可能读不到最新值——尤其是当子窗口被销毁后变量又被重新初始化。更常见的是，用户关掉子窗口时没触发数据回传逻辑，导致主界面“以为”数据已更新，实际仍是旧值。
-
Toplevel实例生命周期独立，不能靠闭包自动捕获父窗口状态 - 直接用
global修改变量在复杂交互中易引发竞态，比如多个子窗口同时改同一变量 - 没有显式回调或事件绑定时，主窗口无法感知子窗口何时提交了数据
推荐做法：让子窗口在关闭前主动通知父窗口，而不是等父窗口去“查”。
用 wait_window() 阻塞等待子窗口关闭并取回数据
wait_window() 是 Tkinter 原生支持的同步等待机制，它会挂起当前线程（不阻塞GUI响应），直到指定的 Toplevel 窗口被销毁。关键在于：你可以在子窗口销毁前，把数据存到一个可访问的位置（比如实例属性），然后在 wait_window() 返回后立即读取。
def open_editor(self):
editor = tk.Toplevel(self.root)
entry = tk.Entry(editor)
entry.pack()
<pre class='brush:python;toolbar:false;'>def on_save():
# 把数据暂存在 editor 实例上
editor.result = entry.get()
editor.destroy()
tk.Button(editor, text="Save", command=on_save).pack()
editor.wait_window() # 这里会暂停，直到 editor 被 destroy
print("Got:", getattr(editor, 'result', None)) # 安全读取- 必须在子窗口调用
destroy()（不是withdraw()）才能触发wait_window()返回 -
wait_window()只阻塞调用它的那个 widget 所在线程（通常是主窗口的Tk实例），不会卡死整个 GUI - 不适合需要“非模态编辑+实时预览”的场景（这时得换事件驱动方式）
用自定义事件 + bind() 实现非阻塞数据回传
当子窗口需要保持打开、支持多次修改并实时通知主窗口时，wait_window() 就不适用了。Tkinter 允许发送和监听虚拟事件（以 <...> 形式），这是解耦窗口间通信的轻量方式。
立即学习“Python免费学习笔记（深入）”；
- 主窗口先绑定自定义事件：
self.root.bind('<DataUpdated>', self.on_data_updated) - 子窗口在需要回传时调用：
self.parent.event_generate('<DataUpdated>', data=new_value) - 注意：必须传
self.parent（主窗口引用），且event_generate()的data参数只支持字符串或简单类型；复杂结构建议用 JSON 序列化
常见错误：event_generate() 发送后主窗口没响应？检查是否绑定了正确的 widget（通常是 Tk 实例）、事件名拼写、以及是否在子窗口创建时就完成了绑定。
避免用 StringVar 跨窗口自动同步的陷阱
看起来 StringVar 是个好选择——毕竟它支持 trace，能监听变化。但实际中，把同一个 StringVar 实例传给多个窗口的 Entry 或 Label，很容易因销毁顺序错乱导致 TclError: invalid command name。
-
StringVar依赖底层 Tcl 解释器，一旦所属的Tk实例被销毁（比如子窗口关掉），再访问该变量就会报错 - 多个窗口共用一个
StringVar时，trace 回调里的self可能指向已销毁的对象 - 更稳妥的做法是：每个窗口用自己的
StringVar，靠事件或回调做单向同步（比如子窗口改完后调用parent_var.set(new_val)）
真正稳定的跨窗口数据流，从来不是靠“自动同步”，而是靠明确的控制权交接：谁负责持有最终数据、谁负责发起更新、谁负责清理残留引用——这些都得在窗口创建时就约定好，而不是依赖 Tkinter 的隐式行为。
