AddressSanitizer 默认不检测内存泄漏，需显式启用LeakSanitizer：编译加-fsanitize=address,leak、运行前设ASAN_OPTIONS=detect_leaks=1，且程序须正常退出才能触发报告。
AddressSanitizer 本身不检测内存泄漏，ASan 默认只捕获越界访问、Use-After-Free、栈缓冲区溢出等**运行时内存错误**；要查内存泄漏，必须显式启用其泄漏检测器（LeakSanitizer），且需满足特定编译和运行条件。
如何开启 LeakSanitizer（LSan）并确保它真正生效
仅加 -fsanitize=address 不够——LSan 是 ASan 的配套组件，但默认可能被禁用或静默跳过。关键在三处：
- 编译时必须同时指定
-fsanitize=address,leak（注意逗号分隔，不能只写address） - 链接时不能带
-shared或静态链接libc（如-static-libgcc -static-libstdc++），否则 LSan 初始化失败，日志里会显示LeakSanitizer disabled - 运行前需设置环境变量：
export ASAN_OPTIONS=detect_leaks=1（Linux/macOS）；若未设，即使编译含leak，LSan 也不触发
典型编译命令：
g++ -fsanitize=address,leak -g -O0 main.cpp -o main
运行前执行：export ASAN_OPTIONS=detect_leaks=1，再运行 ./main。
立即学习“C++免费学习笔记（深入）”；
为什么程序退出后没输出泄漏报告？常见静默失败原因
LSan 只在进程正常退出（return 或 exit()）时扫描堆，以下情况会导致“无报告”假象：
- 程序因信号崩溃（如
SEGFAULT）——ASan 会报错，但 LSan 不运行 - 主线程调用
pthread_exit()而非return—— 进程未完全终止，LSan 不触发 - 使用了
atexit()注册的清理函数中又分配内存——干扰 LSan 扫描逻辑，可能跳过报告 - 程序中调用了
_exit()或abort()—— 绕过正常退出流程，LSan 无机会运行
验证是否真启用：运行前加 export ASAN_OPTIONS=detect_leaks=1:log_path=asan.log，检查 asan.log.* 文件是否存在泄漏摘要行（含 LEAK SUMMARY）。
clang vs gcc 对 LSan 的支持差异与陷阱
Clang 原生集成 LSan，行为稳定；GCC 从 4.9+ 支持，但有关键限制：
- GCC 10 及更早版本中，
-fsanitize=leak单独使用无效，必须与address联用（即-fsanitize=address,leak） - 某些旧版 GCC（如 7.5）在启用
leak时若链接了libstdc++.so的 debug 版本，可能触发符号冲突导致启动失败 - Clang 编译的二进制可直接用
ASAN_OPTIONS控制 LSan 行为；GCC 编译的则对abort_on_error等选项响应较弱
稳妥做法：优先用 Clang 12+，或确认 GCC 版本 ≥ 11，并避免混用 debug/release 标准库。
泄漏报告看不懂？关键字段解读与过滤技巧
LSan 报告中真正有用的不是堆栈顶层，而是：
-
Direct leak：代码中new/malloc分配后未delete/free -
Indirect leak：指向已泄漏内存的指针也被泄漏（通常可忽略，先修 direct） - 堆栈末尾的
operator new或malloc行号才是泄漏点，不是上层调用者 - 若堆栈只有
__libc_start_main和main，说明泄漏发生在全局对象构造或main开头，检查静态变量/单例初始化
快速定位：用 grep -A 10 "0x[0-9a-f]* is located" asan.log 提取地址上下文，再结合 addr2line -e main -f -C 0x... 反查源码行。
LSan 不是万能的——它无法发现循环引用导致的智能指针泄漏（如 std::shared_ptr 成环），也不跟踪未释放的文件描述符或 mmap 区域；真要覆盖全面，得配合 valgrind --tool=memcheck 或 Dr. Memory。但对裸指针和传统 C 风格内存管理，开对参数的 LSan 就是最轻量、最快的起点。
