std::stacktrace 不是自动崩溃处理器，需手动注册信号处理函数并在其中轻量调用 current() 限制帧数、用 write() 输出、_exit() 终止；需编译选项 -g -rdynamic 且不 strip 才能显示符号名。
std::stacktrace 在崩溃时根本不会自动触发
它不是 crash handler，只是个静态快照工具。程序崩溃（如 SIGSEGV）时，std::stacktrace::current() 不会自动执行——你得自己注册信号处理函数，并在其中手动捕获堆栈。否则，什么都不会打印。
- 崩溃发生时，程序已进入未定义行为区域，直接调用
std::stacktrace::current()可能失败（尤其在栈已损坏时），必须在信号处理函数中尽早、轻量地调用 - 仅 GCC 13+ / Clang 16+ 支持
std::stacktrace；MSVC 完全不支持（截至 VS 2022 17.8），别指望跨平台开箱即用 - 信号处理函数中不能用
std::cout、malloc、std::string构造等非异步信号安全操作——得用write()+std::stacktrace::to_string()的只读视图
如何在 SIGSEGV/SIGABRT 中安全捕获 stacktrace
核心是用 signal() 或 sigaction() 注册处理函数，并限制调用链深度（避免递归崩溃）。推荐用 sigaction()，它更可靠且可屏蔽嵌套信号。
- 在处理函数里立刻调用
std::stacktrace::current(32)，第二个参数限制帧数，防止栈遍历过深导致二次崩溃 - 用
std::string_view s = st.to_string(); write(STDERR_FILENO, s.data(), s.size());输出，绕过 iostream 和内存分配 - 处理完后调用
_exit(1)（不是exit()），跳过 atexit 回调和全局对象析构——这些可能再次触发崩溃 - 记得在 main 开头用
sigaltstack()配置备用栈（SA_ONSTACK），防止主栈溢出时信号处理本身失败
std::stacktrace::to_string() 输出不可读？检查编译选项
默认输出只有地址，没有符号名，是因为缺少调试信息或链接器未保留符号表。这不是 std::stacktrace 的 bug，而是构建配置问题。
- 必须加编译选项：
-g（生成调试信息），-rdynamic（GCC/Clang，等价于--export-dynamic，让动态链接器导出所有符号） - 链接时不能 strip：确保最终二进制没被
strip过，否则to_string()只能显示??? - 如果用了 LTO（
-flto），需配合-grecord-gcc-switches，否则部分内联帧可能丢失源码位置 - macOS 上要用
-Wl,-export_dynamic替代-rdynamic，且需dsymutil处理 dSYM
std::stacktrace 性能开销大吗？什么时候不该用
单次 std::stacktrace::current() 在现代 Linux 上平均耗时约 5–20 μs（取决于帧数），不算昂贵，但绝不适合高频调用场景。
立即学习“C++免费学习笔记（深入）”；
- 不要在 hot path（如 tight loop、高频回调）里调用；崩溃日志场景下一次就够了
- 在容器满、锁争用、内存耗尽等“软崩溃”前主动记录堆栈？可以，但要加条件（如计数器限频），否则可能雪上加霜
- ASan/UBSan 已内置堆栈捕获，此时再手动插
std::stacktrace是冗余的，还可能干扰 sanitizer 的报告格式 - Release 模式下若禁用异常和 RTTI，
std::stacktrace仍可用，但符号解析能力依赖外部 debug info 文件（如 .debug 文件分离部署时需确保路径可达）
真正难的是让崩溃现场的堆栈既完整又安全——信号上下文、栈完整性、符号可用性，三者缺一不可。少配一个，看到的就是一串地址。
