std::stacktrace 是 C++23 引入的特性，需 GCC 13+/Clang 16+ 并启用 -std=c++23；C++20 及更早版本不支持，且在信号处理中不可直接使用，应改用 backtrace + addr2line 等异步安全方案。
std::stacktrace 在 C++23 中才正式可用，C++20 及更早版本无法直接使用
标准库的 std::stacktrace 是 C++23 引入的特性，GCC 13+、Clang 16+ 且启用 -std=c++23 才能编译通过。如果你用的是 GCC 12 或 MSVC 2022（17.5），即使开了 C++23 模式，std::stacktrace 仍可能被禁用或仅提供空实现——运行时调用 std::stacktrace::current() 返回空 trace，不报错但无用。
常见错误现象：std::stacktrace::current().to_string() 返回空字符串，或程序在 std::stacktrace 构造时崩溃（尤其在信号处理上下文中）。
- 确认编译器版本与标准：运行
g++ --version并检查是否 ≥13，再加-std=c++23 -fexceptions -g - 链接时需确保调试信息完整：
-g不可省略，否则 symbol 名称全为??? - 避免在
SIGSEGV信号处理函数中直接构造std::stacktrace—— 它可能触发内存分配或调用 unsafe 函数，导致二次崩溃
崩溃时捕获 stacktrace 必须绕过异常机制，改用信号 + libbacktrace 或 addr2line
当程序因空指针解引用、栈溢出等触发 SIGSEGV / SIGABRT 时，C++ 异常根本不会抛出，try/catch 完全无效。此时 std::stacktrace::current() 无法在崩溃点自动执行，必须提前注册信号处理器，并在 handler 中安全采集调用栈。
但注意：std::stacktrace 的构造函数不是 async-signal-safe，不能在 signal handler 中直接调用。正确做法是：用 sigaltstack 配合备用栈，然后调用 backtrace + backtrace_symbols（glibc）或 libbacktrace（更可靠）。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- Linux 下推荐轻量方案：在信号 handler 中调用
backtrace()获取地址数组，再用addr2line -e ./a.out -f -C -p离线解析（确保二进制含 debug info） - 若坚持用 C++23
std::stacktrace，只能用于「主动诊断」场景，例如在可疑函数入口插入std::cerr - Windows 上无原生
std::stacktrace支持，需用StackWalk64或第三方如boost::stacktrace
std::stacktrace::current() 无法穿透 inline 函数或优化掉的帧
即使开启 -g，GCC/Clang 在 -O2 下会内联小函数，导致 std::stacktrace::current() 返回的帧数少于实际调用深度。比如 A() → B() → C()，若 B() 被内联，则 trace 只显示 A 和 C，中间断层。
- 临时调试时加
-O0 -fno-omit-frame-pointer，强制保留栈帧信息 -
[[gnu::noinline]]或__attribute__((noinline))可阻止特定函数被内联，适合标记关键路径上的中间函数 -
std::stacktrace不解析模板实例化名细节，foo<int></int>可能显示为foo，需结合addr2line -C查看完整符号
深层嵌套崩溃定位真正依赖的是符号 + 崩溃地址，不是 stacktrace 对象本身
很多人以为拿到 std::stacktrace 就等于定位到 bug，其实不然。它只是地址到符号名的映射结果，一旦二进制 strip 过、或动态库未加载 debuginfo，所有帧都变成 ???。真正起作用的是 core dump 配合 gdb ./a.out core，或直接用 addr2line -e ./a.out 0x7f8a12345678 查原始地址。
- 生产环境部署前，务必保留未 strip 的 debug 二进制（或分离出 .debug 文件），否则
std::stacktrace::to_string()输出毫无意义 - 对 shared library 中的崩溃，需确保
LD_LIBRARY_PATH正确，且对应 so 文件带调试段 -
std::stacktrace本身不包含源码行号（除非编译器支持并生成了 DWARF line info），行号需靠addr2line或gdb补全
深层嵌套里哪个函数真正踩了空指针，从来不是靠堆栈“层数”判断的，而是看最靠近崩溃地址的那一帧——那帧的汇编指令和寄存器值，才是唯一可信线索。
