asan报错后无法安全继续运行，唯一可控方式是启动前设置asan_options="abort_on_error=0"，但程序逻辑仍可能因内存破坏而崩溃，仅适用于调试；生产环境禁用，应优先修复首个错误。
ASan 报错后程序直接退出，怎么让它继续跑？
默认情况下，AddressSanitizer（ASan）检测到内存错误（如 use-after-free、heap-buffer-overflow）会调用 abort()，进程立刻终止。你没法靠 try/catch 捕获——ASan 的错误不是 C++ 异常，是信号（通常是 SIGABRT 或 SIGSEGV），且默认不提供继续执行的入口。
abort_on_error=0 是唯一可控开关，但有硬限制
必须在 ASan 启动前通过环境变量控制，运行时无法修改。关键点是：它只让 ASan **打印错误后不 abort**，但**不保证程序逻辑安全继续**——踩了堆溢出还往下跑，极大概率触发二次崩溃或未定义行为。
- 启用方式：
ASAN_OPTIONS="abort_on_error=0" ./your_program - 注意：
continue_on_error不是合法选项名，ASan 官方文档和源码中只有abort_on_error=0有效 - 它不会跳过错误检查，每次再触发同类问题仍会重复报告
- 仅适用于调试场景（比如想看一连串越界位置），生产环境禁用
为什么不能靠 signal handler + longjmp 续命？
有人试过捕获 SIGABRT 后 longjmp 回主循环——这非常危险：
- ASan 内部可能已破坏栈帧或寄存器状态，
longjmp会跳进不可信上下文 - 报错点之后的代码若依赖被破坏的内存（如指针已被 free），继续执行等于主动触发新 UB
- Clang/LLVM 的 ASan 实现明确不保证信号处理后的可恢复性，属于未定义行为
- 即使“看起来”跑下去了，结果不可信，日志也难追溯真实源头
真要观察多处错误，正确做法是分段隔离
与其强行续命，不如把可疑逻辑拆开，逐个验证：
- 用
__asan_report_explicit()手动触发检查（需包含<sanitizer></sanitizer>），配合条件编译定位范围 - 对高风险模块（如解析器、序列化）单独编译链接 ASan，其他模块关掉，避免干扰
- 结合
detect_stack_use_after_return=1和strict_string_checks=1提前暴露隐性问题 - 错误集中爆发时，优先看第一个 ASan 报告——后续报错往往是前一个破坏的连锁反应
ASan 的设计哲学就是“错即停”，强行绕过它最核心的安全边界，相当于关掉安全气囊还猛踩油门。真正该花时间的，是让第一个错误不发生。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
