sys.excepthook对Tkinter异常无效，是因为Tkinter的C层事件循环（mainloop）会拦截并吞掉主线程中按钮回调等GUI事件抛出的未捕获异常，使其无法冒泡至Python解释器顶层；真正生效的是Tkinter专设的root.report_callback_exception回调，需在创建Tk实例后立即重写该方法以捕获GUI线程异常。
为什么 sys.excepthook 对 Tkinter 异常无效
Tkinter 的事件循环（mainloop()）会拦截并吞掉大多数未捕获异常，导致你设置的 sys.excepthook 完全不触发。这不是 bug，而是 Tk 的底层行为：它用 C 层的 Tcl_Panic 或内部错误处理绕过了 Python 的异常传播链。你看到界面卡死、控制台静默、日志没记录，大概率就是掉进这个坑了。
真正起作用的是 Tk 自己的异常钩子：tcl.eval('catch {::tk::MessageBox...}') 不行，得用 report_callback_exception —— 这是 Tkinter 唯一暴露给 Python 层的、专为 GUI 线程异常设计的回调。
必须重写 root.report_callback_exception
这个方法只在 Tkinter 主线程中抛出未处理异常时调用（比如 Button 的 command 回调里出错），它接收三个参数：exc_type、exc_value、exc_traceback。覆盖它是最小侵入、最可靠的方式。
- 必须在创建
Tk()实例后立即设置，不能等mainloop()启动后再赋值 - 不要在回调里再抛异常，否则会无限递归崩溃
- 如果用了多窗口（
Toplevel），每个窗口实例都要单独设置，root的设置不会继承
import tkinter as tk
import traceback
import logging
<p>root = tk.Tk()
root.title("Demo")</p><p>def my_exception_handler(exc_type, exc_value, exc_traceback):
logging.error("Uncaught Tkinter exception:", exc_info=(exc_type, exc_value, exc_traceback))</p><h1>可选：弹窗提示用户，但避免用 tk.messagebox（它自己可能出错）</h1><pre class="brush:php;toolbar:false;">print(f"[ERROR] {exc_type.__name__}: {exc_value}")root.report_callback_exception = my_exception_handler
立即学习“Python免费学习笔记（深入）”；
测试：按钮触发一个 NameError
btn = tk.Button(root, text="Crash me", command=lambda: undefined_var + 1) btn.pack() root.mainloop()
如何捕获 after() 和异步回调中的异常
after()、after_idle()、绑定事件（如 bind('<button-1>')</button-1>）里的异常，同样走 report_callback_exception，无需额外处理——前提是这些回调确实在 Tk 主线程执行（它们默认就是）。但要注意：
- 如果你用
threading.Thread在后台线程更新 UI（比如调用label.config(text=...)），Tk 会直接报TclError: can't invoke "configure" command: application has been destroyed，这种不属于report_callback_exception范围，必须用线程内try/except -
after(0, ...)是安全的，但after(1, ...)以上若回调抛异常，仍由report_callback_exception捕获 - 自定义的
StringVar.trace()回调也走同一套机制
别碰 tk.call('console', 'show') 或 tk.eval 魔改
网上有些方案建议用 tk.eval('set tcl_interactive 1') 或劫持 bgerror Tcl 过程，这些在 Python 3.11 + Tk 8.6+ 上基本失效或引发不可预测行为（比如窗口假死、mainloop() 提前退出）。Tkinter 的 Python 绑定层已经封装了足够干净的接口，强行下探 Tcl 层只会增加维护成本和兼容性风险。
真正需要扩展的点只有一个：在 report_callback_exception 回调里，你可以集成 Sentry、写入本地文件、甚至调用 logging.exception 并带上当前 widget 路径（通过 root.focus_get() 或 event.widget，如果上下文可用）。但核心逻辑必须守住——不替换钩子，不绕过主线程，不假设异常发生位置。
