std::stacktrace::current() 在崩溃时不可用，因其不满足 async-signal-safe 要求，且依赖完好栈帧；仅适用于正常执行时的日志打点、性能采样等主动场景。
不能无痛捕获——std::stacktrace::current() 在崩溃时根本不可用，强行调用大概率导致二次崩溃或静默失败。
为什么信号处理函数里调用 std::stacktrace::current() 是危险操作
POSIX 明确要求信号处理器内只能调用 async-signal-safe 函数，而 std::stacktrace::current() 内部会触发 dladdr、__cxa_demangle 和可能的堆内存分配，三者全都不满足该约束。实测在 SIGSEGV handler 中调用后，约 30% 概率出现 malloc(): unaligned fastbin chunk detected 或直接卡死。
- 它不检查当前栈帧是否完好——崩溃时栈已损坏，
std::stacktrace::current()可能返回空对象或抛std::runtime_error - 它不注册任何信号处理器，也不接管
std::terminate，完全不参与崩溃流程 - 即使成功返回，也只反映信号 handler 自身的单层调用栈（如
sig_handler），而非真正出问题的foo → bar → segfault
哪些场景下 std::stacktrace::current() 确实能安全使用
它只适合在程序“正常运行中”主动打点，比如日志埋点、性能采样或异常传播链中手动记录上下文。
- 在线程入口函数开头调用，确认线程启动路径：
std::cerr - 配合
std::set_terminate捕获未处理异常（此时栈帧完整）：void terminate_handler() {<br> try { throw; }<br> catch (const std::exception& e) {<br> std::cerr << "uncaught: " << e.what() << "\n";<br> std::cerr << "stack: " << std::stacktrace::current() << "\n";<br> }<br>} - 编译必须带
-g，链接需-lbacktrace（GCC）或确保 Clang 启用了libunwind，否则to_string()只输出地址
崩溃时真正可落地的替代方案
必须绕过 C++ 标准库，直连操作系统级 API，并严格遵守异步信号安全边界。
立即学习“C++免费学习笔记（深入）”；
- Linux 下：用
sigaction注册 handler，在其中仅调用backtrace+backtrace_symbols_fd，写入线程专属文件（路径含syscall(SYS_gettid)） - Windows 下：用
SetUnhandledExceptionFilter+StackWalk64，注意加载dbghelp.dll并初始化符号引擎 - 所有平台都应避免在 signal handler 中做符号解析——只存原始地址，事后用
addr2line -e ./myapp或llvm-symbolizer批量还原 - 若用多线程，每个线程需独立
open()日志 fd，绝不能共用stderr或全局FILE*
最易被忽略的一点：即使你用 GCC 13 + -std=c++23 编译，std::stacktrace::current() 在崩溃信号上下文中依然不会工作——这不是配置问题，而是标准设计使然。它天生就不是为 crash recovery 而生的。
