std::set_terminate是唯一可靠的全局异常终止入口，因其进程级生效且覆盖所有线程的terminate调用，而try/catch无法捕获thread构造、TLS析构、noexcept违规等场景的异常。
为什么std::set_terminate是唯一可靠的入口
在多线程 C++ 程序中，未捕获异常（uncaught exception）只会在**栈展开失败时触发终止处理**，而每个线程的异常若未被该线程内 catch 捕获，最终都会调用该线程所属的 std::terminate —— 注意：不是全局统一调用一次，而是每个线程各自触发。但标准规定：std::terminate 的行为由 std::set_terminate 设置的函数决定，且该设置是**进程级全局生效**的。这意味着你只需安装一次自定义 handler，就能覆盖所有线程的终止路径。
常见错误是试图在线程入口函数里加 try/catch(...) 包裹全部逻辑 —— 这能捕获本线程抛出的异常，但无法覆盖 std::thread 构造函数内部、线程局部存储（TLS）析构、或 std::async 启动时发生的异常；更关键的是，它漏掉 noexcept 函数违反契约导致的 std::terminate 调用（比如析构函数抛异常）。
- 必须在
main()开头（甚至早于任何线程创建）调用std::set_terminate - handler 函数必须为
noexcept，否则会二次调用std::terminate导致直接 abort - 避免在 handler 中调用
std::cout、std::cerr或任何可能抛异常/依赖锁的设施
如何安全写入日志而不死锁或崩溃
终止 handler 运行在“异常上下文已损坏”的状态：栈正在解退、内存可能不一致、std::mutex 等同步原语不可用。此时唯一可信赖的 I/O 是 write() 系统调用（POSIX）或 WriteFile()（Windows），且必须使用预先分配好的缓冲区和文件描述符。
典型做法是提前打开日志文件，保存其 int fd（Linux/macOS）或 HANDLE（Windows），并在 handler 中用原子方式写入固定长度字符串。不要格式化、不要 strftime、不要 snprintf（可能调用 malloc 或 locale 相关函数）。
立即学习“C++免费学习笔记（深入）”；
- 在
main()初始化阶段用open("crash.log", O_WRONLY | O_APPEND | O_CREAT, 0644)获取log_fd - handler 中用
write(log_fd, "UNCAUGHT in thread 1234\n", 25)这类确定长度的写入 - 线程 ID 可通过
std::this_thread::get_id()转为std::hash<std::thread::id>{}(id)得到整数，再转为 ASCII 字符串（需预分配缓冲区） - 绝对不要调用
backtrace()或abi::__cxa_demangle()—— 它们依赖堆和符号表，在 terminate 时极不稳定
std::set_unexpected已废弃，别碰它
C++17 起 std::set_unexpected 被标记为 deprecated，C++20 正式移除。它原本用于处理违反 noexcept 规约的异常传播，但实际中几乎无法可靠实现日志 —— 因为 unexpected handler 同样受制于栈损坏，且现代编译器（如 GCC/Clang）在启用 -fno-exceptions 或优化后可能完全绕过该机制。依赖它等于给日志功能埋雷。
- 删除所有对
std::set_unexpected的调用和声明 - 把精力集中在加固
std::set_terminatehandler 上 - 用静态分析（如 Clang’s
-Wexceptions）和单元测试确保关键析构函数、noexcept函数不抛异常
多线程下仍需额外防御：线程局部未捕获异常
std::set_terminate 覆盖所有线程，但有个盲区：如果线程通过 std::thread 启动，其入口函数返回后，线程自动析构；若析构过程中（例如 thread_local 对象的 destructor）抛异常，则直接调用 std::terminate —— 这仍是同一 handler，没问题。真正麻烦的是 std::async 和 std::packaged_task：它们把异常“捕获并存储”在 std::future 中，不会触发 terminate，但若用户忘记调用 get()，异常就永远沉底，无法日志化。
- 对所有
std::async调用，强制包装一层：用std::launch::deferred或手动管理std::future生命周期 - 在 RAII wrapper 中（如
auto task = make_async(...);），析构时检查future.wait_for(0s) == std::future_status::ready，再调用get()并记录 - 禁止裸用
std::packaged_task；改用封装了异常检查的 task runner 类
最棘手的部分不是写 handler，而是让整个代码库接受“异常必须显式消费”的约束 —— 否则日志永远有漏网之鱼。
