sys.excepthook仅捕获主线程未处理异常，需早期设置并配合logging.error(..., exc_info=True)；子线程需threading.excepthook（Python 3.8+）或手动包装，asyncio需set_exception_handler()，避免与except重复记录。
使用 sys.excepthook 替换默认异常处理器
Python 默认会在未捕获异常时打印 traceback 到 stderr 并退出。要接管这个行为，必须在程序启动早期（比如 main() 开头或模块顶层）重设 sys.excepthook。它接收三个参数：exc_type、exc_value、exc_traceback，正好对应 sys.exc_info() 的返回值。
常见错误是只在某个函数里设置，但没覆盖全局；或者设置了却忘了调用 logging.error() 带上完整 traceback。
- 务必在导入其他模块前设置，避免第三方库提前触发异常
- 不要直接 print 或 print_exc()，否则和 logging 冲突且无法控制格式
- 推荐用
logging.error(..., exc_info=(exc_type, exc_value, exc_traceback))，这样能自动渲染 traceback
import sys
import logging
logging.basicConfig(level=logging.ERROR, format='%(asctime)s %(levelname)s %(message)s')
def log_uncaught_exception(exc_type, exc_value, exc_traceback):
logging.error("Uncaught exception", exc_info=(exc_type, exc_value, exc_traceback))
sys.excepthook = log_uncaught_exception
区分主线程与子线程的异常捕获
sys.excepthook 只对主线程生效。多线程环境下，子线程抛出的未处理异常不会触发它，而是静默丢弃（除非启用了 threading.excepthook，但该功能从 Python 3.8 才引入，且默认不启用）。
如果你用 threading.Thread，必须显式包装 run() 方法，或统一用 concurrent.futures 等更可控的抽象。
立即学习“Python免费学习笔记（深入）”；
- Python 3.8+ 可设置
threading.excepthook，但需注意它接收的是threading.ExceptHookArgs对象，不是原始三元组 - 老版本只能靠手动 try/except 包裹每个
target函数 - 异步任务（如
asyncio.create_task）同样不走sys.excepthook，需用asyncio.get_event_loop().set_exception_handler()
避免日志重复记录已捕获的异常
很多人把 sys.excepthook 和到处写的 except Exception: 混用，结果同一个异常被记录两次：一次在 except 块里，一次在 excepthook 中——因为后者仍会被触发（只要没被 except 完全吞掉）。
关键判断点在于：只有真正“未处理”的异常才应由 excepthook 记录。如果代码中已有明确 except，就不要再让它漏下去。
- 确保
except块末尾没有raise或raise e（会重新抛出） - 若需记录后继续传播，用
raise（不带参数），它保留原始 traceback，且不会触发excepthook - 用
logging.exception()替代logging.error(..., exc_info=True)更简洁，效果相同
注意 logging 配置时机与 root logger 状态
如果在设置 sys.excepthook 前没配置好 logging，比如没调用 basicConfig() 或没加 handler，那么异常日志会输出到 stderr（logging 默认 fallback 行为），看起来像没生效。
另一个容易忽略的点是：某些框架（如 Flask、Django）会自行配置 root logger，可能覆盖你的设置，导致日志格式或级别不符合预期。
- 检查
logging.getLogger().handlers是否为空，确认 handler 已注册 - 避免在 except 块里临时调用
basicConfig()，它只在首次生效 - 生产环境建议用
dictConfig或配置文件管理，避免隐式状态干扰
