std::stacktrace 需手动调用 current() 捕获堆栈，非自动崩溃上报；linux 生产环境倾向 backtrace + backtrace_symbols_fd 以保证信号安全、可控符号解析；windows 优先用 capturestackbacktrace 实现轻量容错堆栈捕获。
std::stacktrace 不会自动捕获崩溃堆栈，必须手动在信号处理器或异常捕获点调用 std::stacktrace::current()；它不是“开箱即崩即报”的工具，而是需要你主动快照的轻量级容器。
Linux 下用 backtrace + backtrace_symbols_fd 替代 std::stacktrace 的真实原因
尽管 C++23 引入了 std::stacktrace，但在 Linux 生产环境里，backtrace 仍是更可控的选择：
-
std::stacktrace::current()在 glibc 实现中底层仍调用backtrace，但封装层屏蔽了地址解析细节，无法直接控制符号解析行为 - 信号处理函数中调用
backtrace_symbols是不安全的（内部 malloc + dlsym），而backtrace_symbols_fd只做 write，是 async-signal-safe 的唯一可行路径 - 编译时漏加
-rdynamic，std::stacktrace的to_string()同样返回一堆??—— 它不绕过符号导出限制 - 若需行号（
foo.cpp:42），std::stacktrace默认不提供，必须额外集成libdw或 forkaddr2line，和backtrace路线无本质区别
Windows 上 CaptureStackBackTrace 比 StackWalk64 更适合信号/异常上下文
在 SEH 或 Vectored Exception Handler 中，优先选 CaptureStackBackTrace：
-
CaptureStackBackTrace是纯用户态、零依赖的轻量捕获，不依赖 CONTEXT、不调用 Sym* 系列函数，天然适配异常上下文 -
StackWalk64必须传入完整CONTEXT，而异常发生时的EXCEPTION_POINTERS->ContextRecord是有效且唯一的入口，但它要求你提前调用SymInitialize—— 若初始化失败（比如符号路径错、权限不足），整个堆栈就退化为裸地址 -
CaptureStackBackTrace返回的是void*地址数组，后续再用SymFromAddr单独解析（可异步、可重试），比StackWalk64一次性强耦合更容错 - 注意：
CaptureStackBackTrace最多返回 62 帧（Windows 内部限制），如需更深堆栈，必须切到StackWalk64并自行管理帧遍历
信号处理器里写堆栈日志的三个硬约束
无论用 backtrace 还是 std::stacktrace::current()，只要在 SIGSEGV/SIGABRT handler 中输出，就必须遵守：
- 只调用 async-signal-safe 函数：可用
write()，禁用printf、std::cout、malloc、new、std::string构造 -
backtrace安全，backtrace_symbols不安全；std::stacktrace::current()安全，但operator 或 <code>to_string()不安全 —— 它们可能触发内存分配或动态链接 - 输出目标只能是已打开的 fd（如
STDERR_FILENO或预先 open 的 crash.log），不能在 handler 里 fopen/fdopen，也不能用 iostream 流缓冲
真正难的从来不是“怎么拿到堆栈”，而是“在程序已经失稳的那一刻，还能安全地把它记下来”。所有看似高级的 API，一旦脱离 async-signal-safe 边界，就只是精致的陷阱。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
