Clang -fsanitize 报错时应先看错误行末尾的 sanitizer 类型标识，如“==12345==ERROR: AddressSanitizer: heap-use-after-free”，它明确指示问题类型；不同 sanitizer 行为不同，如 -fsanitize=undefined 默认仅警告而不中止，需配合 -fno-sanitize-recover 才终止程序。
Clang -fsanitize 报错时，先看错误行末尾的 sanitizer 类型标识
Clang 的地址/内存/未定义行为等检查器会在崩溃时打印带颜色（或前缀）的错误信息，关键不是第一行堆栈，而是末尾类似 ==12345==ERROR: AddressSanitizer: heap-use-after-free 这样的标识。它直接告诉你触发的是哪类问题：是 heap-use-after-free、stack-buffer-overflow、undefined-behavior 还是 integer-divide-by-zero。不同 sanitizer 的行为差异很大——比如 -fsanitize=address 会拦截非法内存访问并中止程序，而 -fsanitize=undefined 默认只打印警告不中止（除非加 -fno-sanitize-recover），这点常被忽略。
常见报错对应的真实代码问题
报错信息里通常包含出错源码行号和变量名，但需注意它反映的是“观测点”，不一定是根源。例如：
-
heap-use-after-free on address 0x602000000040 at pc 0x00010d8e3c7d bp 0x7ffeeb3a9a20 sp 0x7ffeeb3a9a18→ 看pc（程序计数器）对应源码行，但真正问题可能在更早的delete p后又用了p->field -
runtime error: load of null pointer of type 'int'→ 不是空指针解引用本身报错，而是你对int*类型做了读操作（如*ptr），Clang 检测到该指针为nullptr -
signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'→ 直接对应 C 标准未定义行为，不是 warning，是运行时报错；若用unsigned int则不会触发此检查
为什么加了 -fsanitize 却没报错？
这比报错更危险，说明配置可能没生效。检查以下几点：
- 确保编译和链接都加了同一组
-fsanitize=xxx参数，例如只在clang++ -fsanitize=address编译但没在链接时加，会导致 runtime missing symbol -
-fsanitize=address需要链接 ASan 运行时库，macOS 上可能因 SIP 或 dylib 路径问题静默失败，可加-v看 clang 是否调用了libclang_rt.asan_osx_dynamic.dylib - 优化级别影响检测能力：
-O2可能导致某些越界访问被优化掉，从而逃过 ASan 检查；调试阶段建议用-O0 -g - 部分 sanitizer 不兼容：比如
-fsanitize=address,undefined在 Clang 15+ 才稳定支持，旧版本混用可能只启用其中一个
报错信息太长、定位困难怎么办
Clang 默认输出完整堆栈和内存映射，但关键信息常被淹没。实用技巧：
- 用
2>&1 | grep -A5 -B5 "ERROR\|runtime error"快速过滤核心段 - 加
-fsanitize-address-use-after-scope（ASan 子选项）能捕获栈变量释放后使用，但会显著拖慢运行速度，仅用于专项排查 - 若程序多线程，ASan 默认开启
-fsanitize=thread的替代方案更轻量，但检测粒度不同；TSan 报错格式类似，但提示词是Data race - 对复杂项目，建议分模块单独编译测试，避免整个程序启动就崩溃掩盖真正问题点
