默认 sys.excepthook 不够用，因其仅输出无时间戳、不落盘、不区分环境的堆栈，无法满足线上问题回溯需求；需安全替换为自定义钩子，兼容多线程、避免二次异常，并正确传递 exc_info。
为什么默认的 sys.excepthook 不够用
Python 进程中未被 try/except 捕获的异常，会由 sys.excepthook 处理并打印到 sys.stderr。但默认行为只有堆栈输出、无时间戳、不落盘、不区分环境，线上服务出问题时根本没法回溯——比如后台线程崩溃、atexit 里抛异常、甚至信号处理回调中出错，都可能绕过常规日志逻辑。
如何安全替换 sys.excepthook 并写入日志文件
直接赋值 sys.excepthook = my_hook 是可行的，但要注意三点：不能在钩子里再抛异常（否则进程直接 abort），要兼容多线程场景，且需确保日志 handler 已初始化完毕。
- 用
logging.getLogger()获取已有 logger，避免重复配置；若没初始化，先调用logging.basicConfig()设置文件 handler - 钩子函数签名必须是
(exc_type, exc_value, exc_traceback)，三参数缺一不可 - 务必用
logging.error(..., exc_info=(exc_type, exc_value, exc_traceback))传入原始 traceback，否则只记最后一行 - 避免在钩子里调用可能阻塞或抛异常的操作，比如网络请求、数据库写入、未加锁的全局变量修改
import sys
import logging
logging.basicConfig(
level=logging.ERROR,
filename="/var/log/myapp/error.log",
format="%(asctime)s %(levelname)s %(message)s",
datefmt="%Y-%m-%d %H:%M:%S"
)
def global_exception_handler(exc_type, exc_value, exc_tb):
logger = logging.getLogger()
logger.error("Uncaught exception", exc_info=(exc_type, exc_value, exc_tb))
sys.excepthook = global_exception_handler
主线程 vs 子线程的异常捕获差异
sys.excepthook 只对主线程生效。子线程中未捕获的异常不会触发它，而是静默丢弃（除非使用 threading.excepthook，Python 3.8+ 才支持）。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- Python threading.Thread 的
run()中手动包一层try/except - Python ≥ 3.8：可设置
threading.excepthook，签名与sys.excepthook一致，但注意它不继承主线程的 logger 配置 - 异步任务（如
asyncio.create_task）同样不走sys.excepthook，需用asyncio.get_event_loop().set_exception_handler()
容易被忽略的崩溃场景：信号、fork、atexit
这些场景下 sys.excepthook 完全不触发：
立即学习“Python免费学习笔记（深入）”；
-
os.kill(os.getpid(), signal.SIGSEGV)类强制终止，直接退出，不给 Python 机会 -
os.fork()后子进程会复制原excepthook引用，但若父进程已重置过，子进程未必同步——建议 fork 后在子进程中重新设置 -
atexit回调里抛异常？会被忽略，且不记录——必须在回调内部自行try/except+logging
真正兜底的方案从来不是单靠 sys.excepthook，而是结合进程级监控（如 systemd 的 Restart=on-failure）、核心转储分析、以及关键路径的主动防御式日志。
