std::stacktrace在GCC 13.1+（需-g -fno-omit-frame-pointer并链接libbacktrace）和Clang 17+（部分平台不完整）才可用，Windows下基本不可用，构造开销大且依赖调试信息与符号库。
std::stacktrace 在 GCC 13+ 中才真正可用
别在 GCC 12 或 Clang 下试 std::stacktrace——它只是个空壳，to_string() 返回空字符串，size() 永远是 0。GCC 13.1 起才默认启用完整实现（需链接 libbacktrace），且必须编译时加 -g 和 -fno-omit-frame-pointer。Clang 17+ 对 std::stacktrace 的支持仍不完整，部分平台（如 macOS）甚至未实现符号解析逻辑。
- 确认编译器版本：
g++ --version | grep -E "(GCC|clang)" - 编译命令必须包含：
g++ -std=c++23 -g -fno-omit-frame-pointer -o trace trace.cpp - 运行前确保调试信息未被 strip：
file ./trace应显示 “not stripped”
std::stacktrace::to_string() 返回空？检查 libbacktrace 是否加载成功
std::stacktrace 不是纯用户态实现，它依赖系统级 backtrace 库。Linux 下若未链接 libbacktrace（GCC 自带）或 libdw（用于 DWARF 解析），to_string() 就只输出地址，不带函数名。常见现象是每行形如 0x7f8a1b2c3d4e，而非 my_func(int) at main.cpp:42。
- 用
ldd ./trace | grep backtrace确认是否链接了libbacktrace.so - 若缺失，显式链接：
g++ -std=c++23 -g -fno-omit-frame-pointer -lbacktrace trace.cpp -o trace - 某些发行版（如 Alpine）默认不装
libbacktrace-dev，需先apk add g++ libbacktrace-dev
std::stacktrace 构造开销大，别在 hot path 频繁调用
每次构造 std::stacktrace 都触发内核 readelf-级的符号表遍历，实测在 x86_64 上采集 20 层堆栈平均耗时 30–80 μs，比 backtrace() + backtrace_symbols() 慢一个数量级。它不适合性能敏感路径，比如 tight loop、高频回调、实时音频处理线程。
- 只在错误日志、断言失败、信号处理（如
SIGSEGVhandler）中使用 - 避免在
operator new、std::shared_ptr构造等底层设施里调用 - 若需轻量级地址快照，改用
std::array<void> frames; int n = backtrace(frames.data(), frames.size());</void>
Windows 下 std::stacktrace 基本不可用，换用 CaptureStackBackTrace + SymFromAddr
MSVC 直到 VS2022 17.8 仍未实现 std::stacktrace 的符号解析，to_string() 恒为地址列表。必须手动调用 Windows API：CaptureStackBackTrace 获取帧指针，再用 SymFromAddr 查询 PDB 符号。注意 PDB 必须与二进制同目录或在 _NT_SYMBOL_PATH 中可查。
立即学习“C++免费学习笔记（深入）”；
- 初始化符号系统：
SymInitialize(GetCurrentProcess(), nullptr, TRUE) - 捕获后逐帧调用
SymFromAddr，需传入模块基址（用GetModuleHandle(nullptr)） - 记得
#include <windows.h>、<dbghelp.h>，并链接dbghelp.lib
std::stacktrace 就退化成地址列表——而这个退化行为不会报错，只会静默失效。 
