做不到。std::stacktrace::current() 非 async-signal-safe，崩溃时栈帧可能已损坏，且依赖 libbacktrace/libunwind 等外部库，MSVC 甚至不支持；真正无外部依赖的方案只能用系统 API（如 Linux 的 backtrace）。
std::stacktrace 无法在崩溃时无外部依赖抓取调用栈
直接回答：做不到。std::stacktrace::current() 本身不是崩溃捕获机制，它只在正常执行流中安全可用；一旦触发 SIGSEGV、SIGABRT 等信号，栈帧可能已损坏，且该函数**不是 async-signal-safe**，不能在信号处理函数中可靠调用——更谈不上“无外部依赖”。
为什么 std::stacktrace::current() 在崩溃点根本拿不到有效栈
常见错误现象是：注册了 SIGSEGV 处理器，里面调用 std::stacktrace::current()，结果输出为空、抛 std::runtime_error，或只显示信号处理函数自身一层帧（如 signal_handler at ???）。
- 崩溃发生时，调用栈可能已被破坏（比如栈溢出、非法内存覆盖），
std::stacktrace::current()依赖的帧指针或.eh_frame信息不可读 - C++23 标准明确允许该函数“may throw”，不保证返回非空结果
- 即使编译器支持（GCC 13+/Clang 16+），其底层仍需
libbacktrace或libunwind—— 这本身就是外部依赖，且必须显式链接（-lbacktrace） - MSVC 完全不支持
std::stacktrace，连 stub 都没实现
真正能“无外部依赖”的方案只有系统级 API
所谓“无外部依赖”，是指不链接第三方库（如 boost、abseil），但必须用操作系统提供的原生接口。这些接口不是 C++ 标准的一部分，但无需额外安装运行时：
- Linux：用
backtrace()+backtrace_symbols_fd()（来自 glibc，所有 Linux 发行版自带） - macOS：用
backtrace()+backtrace_symbols()（libSystem.dylib 自带） - Windows：用
StackWalk64()+SymInitialize()（DbgHelp.dll 系统自带，无需分发） - 所有平台都可配合
sigaltstack()设置备用栈，避免信号处理时栈溢出
示例（Linux）：
void segv_handler(int) {
void* buffer[128];
int nptrs = backtrace(buffer, sizeof(buffer)/sizeof(void*));
backtrace_symbols_fd(buffer, nptrs, STDERR_FILENO);
_exit(1);
}
std::stacktrace 唯一安全的崩溃相关用途：未捕获异常
它只在 std::set_terminate 回调中相对可控，前提是确保处于异常传播上下文（否则帧链不完整）：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 必须用
try { throw; } catch(...) { ... }重新进入异常上下文，再调std::stacktrace::current() - 不能在 handler 中用
std::cout或std::string拼接——改用write(2)直写STDERR_FILENO - 仍需
-g编译，否则to_string()只输出地址（如@ 0x55e123456789） - Release 模式若开启
-fomit-frame-pointer（x86_64 默认开），部分帧会丢失
这依然不是“崩溃”（crash），而是“未处理异常”（uncaught exception）——语义和触发时机完全不同。
真正要抓 SIGSEGV 这类崩溃的完整调用链，别碰 std::stacktrace。它设计上就不是干这个的；强行用，只会掩盖问题根源，比如忽略栈损坏、信号安全性、符号解析失败等底层事实。
