std::stacktrace 在 GCC 13+ 才真正可用；GCC 12 及更早版本中为空壳，调用 to_string() 返回空字符串或抛 std::not_implemented；Clang 15+ 需手动启用调试信息；MSVC 自 VS2022 17.5 起支持但需 /Zi 和 PDB。
std::stacktrace 在 GCC 13+ 中才真正可用
别急着在旧项目里写
——它在 GCC 12 及更早版本中只是个空壳，调用
会返回空字符串或抛
。Clang 15+ 支持较完整，但需手动启用调试信息和符号表。MSVC 从 VS2022 17.5 起支持，但默认不包含函数名（只显示地址），必须配合 PDB 和
编译选项。
验证是否生效最直接的方式是：
如果输出全是
或空行，说明符号未加载成功，不是代码写错了，而是编译/链接环节漏了关键配置。
编译时必须保留调试符号且禁用帧指针优化
依赖 DWARF（Linux/macOS）或 PDB（Windows）中的函数名、行号和调用关系。仅加
不够，常见遗漏点包括：
立即学习
“
C++免费学习笔记（深入）
”；
C知道
CSDN推出的一款AI技术问答工具
下载
或
会触发
，导致栈回溯断裂——必须显式加
使用 LTO（
）时，DWARF 可能被剥离，需额外加
静态链接
（
）会导致部分符号丢失，建议动态链接
Strip 操作（如
）会直接清空所有符号——调试阶段务必跳过
std::stacktrace::current() 默认只捕获当前线程栈
它不会自动抓取其他线程的调用栈，也不能跨 signal handler 安全使用（例如在
处理函数里调用可能死锁）。真实场景中要注意：
若想记录崩溃现场，应改用
+
（POSIX）或
（Windows），它们更底层、更稳定
构造开销不小（尤其深栈+符号解析），高频日志中应缓存结果，而非每条日志都调用
它不包含内联函数展开信息，即使源码里有
或编译器自动内联，堆栈里也只显示外层函数名
符号名解析失败的三个典型表现及对策
常见现象：堆栈里出现
、十六进制地址（如
）、或函数名带
却看不到你的业务函数。
Linux 下检查是否启用了
（等价于
），否则动态链接器不会导出全局符号供 backtrace 解析
确保可执行文件未被
或类似工具处理过；可用
确认存在
节
若使用容器或沙箱环境（如 Docker），确认 /proc/sys/kernel/kptr_restrict 设为 0，否则内核隐藏符号地址
符号解析不是黑盒——它本质是查 .debug_line 和 .symtab，任何破坏这两者完整性的操作都会让
失效。别怪标准库，先盯住你的构建流程。
std::stacktraceto_string()std::not_implemented/Ziauto st = std::stacktrace::current();
std::cout << st.to_string() << std::endl;???std::stacktrace-g-O2-O3-fomit-frame-pointer-fno-omit-frame-pointer-flto-grecord-gcc-switcheslibstdc++-static-libstdc++strip ./a.outSIGSEGVbacktrace()backtrace_symbols()CaptureStackBackTracestd::stacktracecurrent()inline???0x7f8b12345678__libc_start_main-rdynamic--export-dynamicobjcopy --strip-unneededreadelf -S ./a.out | grep debug.debug_*std::stacktrace