c++oding="utf-8" ?>
启用asan/tsan/ubsan需编译和链接阶段均加对应-fsanitize=选项及-fno-omit-frame-pointer；asan可静态链接（-static-libasan），tsan不支持静态链接；clang更推荐，gcc 11+对tsan支持不稳定。
编译时启用 ASan/MSan/TSan 需要链接 Sanitizer 运行时库
Clang 和 GCC 在编译期加 -fsanitize=address 这类选项，**不会自动生成检查桩代码**，而是让编译器在 IR 层插入调用（如 __asan_report_load4），再靠链接阶段拉入 libasan 等运行时库来提供具体实现。没链接对应库，会报 undefined reference 错误。
实操要点：
- 必须同时加编译选项和链接选项：GCC/Clang 默认开启链接，但若显式用了
-nostdlib或-shared，就得手动加-lasan、-ltsan等 - ASan 和 MSan 不能共存；TSan 可与 ASan 同时启用（需 Clang ≥14），但实际极少这么做——冲突多、开销爆炸
- 使用
-fsanitize=address,undefined是常见组合，UBSan 桩函数（如__ubsan_handle_out_of_bounds）也由libubsan提供，需确保其被链接
如何让静态库或对象文件也带 Sanitizer 桩
如果把源码编译成 .a 或 .o，再链接进主程序，**必须对每个编译单元都加 -fsanitize=...**。否则：.o 里没插桩，主程序即使开了 ASan，也查不到这个模块的越界访问。
典型错误场景：
- 第三方静态库（如
libfoo.a）未用 ASan 编译 → 主程序开 ASan 后仍漏检该库内的堆溢出 - CMake 中只对可执行目标加
set_target_properties(... PROPERTIES COMPILE_OPTIONS "-fsanitize=address")，却忘了对add_library(foo STATIC ...)做同样设置 - 头文件中内联函数（
inline或constexpr）若定义在未启用 Sanitizer 的 TU 中，其展开体也不会被插桩
TSan 对 std::thread 和原子操作的检查依赖编译器重写
TSan 不是靠拦截系统调用，而是将 std::thread::join()、std::atomic<int>::load()</int> 等全部重定向到 __tsan_acquire、__tsan_release 等桩函数。这些重写发生在编译器前端（Clang）或中端（LLVM IR），所以：
- 必须用支持 TSan 的 Clang（GCC 的 TSan 支持较弱，且不覆盖 C++11 线程库全部接口）
-
std::mutex构造/析构、std::condition_variable::wait()等也会被重写，但前提是它们的定义可见（即你没用预编译的libstdc++.a，而用的是 Clang 自带的libc++或启用了-fsanitize=thread的 libstdc++ 版本） - 直接调用
pthread_create也能被 TSan 拦截，但需确保链接的是libtsan而非原生libpthread
ASan 的栈/全局变量检查在编译期就决定边界，不依赖运行时配置
ASan 对栈上数组（如 int buf[10]; buf[15] = 1;）和全局变量越界的检测，是在编译时计算红区（redzone）大小并生成固定偏移访问的。这意味着：
- 即使关掉
ASAN_OPTIONS=detect_stack_use_after_return=1，栈越界仍会被捕获（因为红区已布好） - 但
detect_stack_use_after_return开启后，会额外分配影子内存并记录栈帧生命周期，这部分行为由运行时控制，编译期无法跳过 - 全局变量红区大小默认为 32 字节，不可改；若结构体字段紧挨着（如
struct { int a; char b; } s;），ASan 可能无法发现s.b后一字节的写——这是设计限制，不是 bug
真正容易被忽略的是：所有参与构建的源文件、所有静态链接的库、所有内联展开点，都得统一用同一套 Sanitizer 选项编译。混用等于部分代码裸奔。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
