为何AddressSanitizer未检测到该C++测试代码的明显内存泄漏

核心原因是你当前的运行环境，完全没满足LeakSanitizer（ASAN附带的泄漏检测组件）的触发条件，常见的坑点按出现概率从高到低排序：

1. CMake配置存在低级错误，ASAN运行时没有正确链接 #

你写的CMAKE_LINKER_FLAGS_DEBUG根本不是CMake官方识别的内置变量，本质是自定义的无作用变量。CMake中负责传递调试模式链接参数的内置变量是：

• CMAKE_EXE_LINKER_FLAGS_DEBUG（针对可执行目标）
• CMAKE_SHARED_LINKER_FLAGS_DEBUG（针对动态库目标）
  你之前的配置只给C++编译命令加了-fsanitize=address，但因为链接环节的变量名写错，根本没把ASAN的运行时参数传给链接器，最终生成的程序没有完整的ASAN运行环境，自然检测不到内存泄漏。
  如果之前程序能正常运行甚至没报ASAN的其他内存错误，大概率是系统编译器默认链接了部分ASAN组件，但没有加载泄漏检测的退出钩子。

2. 退出流程绕开了LSAN的扫描触发点 #

LSAN的工作逻辑不是实时监控每一次new的内存有没有被delete，它的触发完全被动：

只有当整个进程正常从main函数返回、或主动调用exit()退出时，LSAN才会执行一次全堆扫描，对照栈、全局区存储的所有指针，标记出没有任何可达指针指向的堆块，报告泄漏。
很多GoogleTest的运行模式（并行跑用例、fork子进程执行单个用例、断言失败直接abort退出、最后强制用exit(0)结束进程），都会直接绕开LSAN注册的退出钩子，根本不会触发泄漏扫描。哪怕那段new A的内存真的永久泄漏了，只要进程不是正常从main返回结束，LSAN就不会执行检查。
另外如果运行时设置了环境变量ASAN_OPTIONS=detect_leaks=0，LSAN会被完全关闭，不管什么情况都不会报泄漏。

3. 泄漏判断逻辑的误判 #

LSAN判断泄漏的规则非常死板：只要退出扫描时，能在栈、全局内存区域找到某个指向堆块起始地址的指针，它就会认为这块堆块是“程序还在使用的有效内存”，不会标记为泄漏。
你代码里的A* a = new A是测试函数的局部变量，当测试函数执行完返回时，这块栈内存的逻辑权限已经被回收，但物理上存储的指针值并没有被清零覆盖，LSAN扫描时读到这个残留的指针值，就会判定这块堆内存可达，不触发泄漏报告。

4. 平台能力限制 #

如果你是在Windows平台上用MSVC编译的ASAN，MSVC版本的AddressSanitizer从根上就不带LeakSanitizer组件，它只能检测越界访问、use-after-free这类非法内存操作，根本没有主动扫描内存泄漏的能力，自然不会报错。

快速验证方法 #

你可以在测试程序的主逻辑最后，手动调用__lsan_do_leak_check();强制触发一次泄漏扫描，如果这时候能报出那块未释放的A对象内存，就说明之前的问题确实是退出钩子没有正常触发。

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