这确实是个挺纠结的问题——Clang提供的几个核心Sanitizer各自能解决不同的关键问题，但遗憾的是它们没法同时启用，尤其是这三个重量级选手：

无法在同一程序中同时启用-fsanitize=address、-fsanitize=thread和-fsanitize=memory这三种检查器中的两种及以上。

先明确下这三个Sanitizer的核心价值：

• AddressSanitizer (ASAN)：主打检测内存错误，比如越界访问、双重释放、内存泄漏这类常见又致命的问题，日常开发中这类bug出现的概率很高，而且排查难度大，ASAN能精准定位问题点，开销也相对可控（一般是运行速度降1-2倍，内存占用翻倍左右）。
• ThreadSanitizer (TSAN)：专门揪多线程环境下的竞争条件，比如数据竞争、死锁隐患，这类bug复现困难，线上出问题很难排查，但如果你的程序是单线程的，那TSAN对你来说用处就不大。
• MemorySanitizer (MSAN)：检测未初始化内存的读取操作，这类bug有时候会导致诡异的行为，但相对前两者，出现的频率没那么高，而且MSAN的使用门槛更高——它要求整个程序（包括依赖的库）都用MSAN编译，否则会出现大量误报。

回到你的问题：如果没有明确的排查目标，把Sanitizer当预防性工具用，该怎么选？

优先推荐：AddressSanitizer (ASAN) #

ASAN是日常预防性检测的首选，原因很简单：

1. 适用范围广：不管是单线程还是多线程程序，内存错误都是普遍存在的风险，几乎所有C/C++项目都会受益于ASAN的检查。
2. 易用性高：不需要额外处理依赖库（大部分系统库已经提供了ASAN版本，或者编译时自动适配），误报极少，上手成本低。
3. 性价比高：性能开销在可接受范围内，适合集成到日常的CI/CD流程或者本地开发测试中。

什么时候选其他两个？ #

• 如果你的程序是多线程密集型，且已经用ASAN排查过内存问题，可以切换到TSAN做一轮专项的线程安全检测，尤其是涉及共享数据的模块。
• 如果你的程序经常出现难以复现的诡异行为，怀疑是未初始化内存导致的，再考虑用MSAN，但记得要确保所有依赖都能配合MSAN编译，否则误报会让你头疼。

有没有更高效的方式？ #

如果想全面覆盖这三类问题，最靠谱的方式还是分三次编译+测试，可以把这三个编译任务集成到CI流水线里，每次代码提交都自动跑一遍不同Sanitizer的测试。虽然看起来繁琐，但能最大化覆盖潜在的bug——毕竟这三个Sanitizer的检测范围完全不重叠，没法用一个工具替代。

内容的提问来源于stack exchange，提问作者Maxpm