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