AddressSanitizer需编译时启用-fsanitize=address并禁用高阶优化，推荐-O1/-O0加-g；第三方库须同参重编；支持堆/栈越界检测，但栈红区有限；动态链接需配置LD_LIBRARY_PATH或-static-libasan。
编译时必须加 -fsanitize=address 且禁用优化
AddressSanitizer 不是运行时可选工具，它依赖编译器在插桩阶段注入内存访问检查逻辑。不加 -fsanitize=address 就完全没效果；加了但用了 -O2 或更高优化等级，可能导致 ASan 检测失效——比如内联后检查被绕过、栈帧信息丢失、甚至误报变少（其实是漏报）。实操中务必使用 -O1 或 -O0，同时带上 -g 保证符号信息完整：
g++ -O1 -g -fsanitize=address -o myapp main.cpp- 如果链接第三方静态库，这些库也得用同样参数重新编译，否则 ASan 无法跨边界检测（比如越界写进库内部缓冲区）
- 避免混用
-fno-omit-frame-pointer：虽然 ASan 默认启用它，但显式加上更稳妥，尤其在调试栈回溯时
运行时报 ERROR: AddressSanitizer: heap-use-after-free 怎么定位
这类错误说明你访问了已 delete 或 free() 的堆内存。ASan 会打印出分配和释放的完整调用栈，但关键要分清「谁释放的」和「谁访问的」：
- 看报错末尾的
#0 0x... in ...行——这是非法访问点，通常是你代码里的某行指针解引用 - 往上找带
freed by thread T0 here:的区块——那里是delete发生位置；再往上找allocated by thread T0 here:——那是原始new位置 - 常见陷阱：对象被
std::unique_ptr管理，但在 lambda 捕获中存了裸指针；或容器erase()后继续用迭代器（迭代器失效即野指针）
栈上越界（如数组下标负数、超过长度）也能被 ASan 捕获
很多人以为 ASan 只管堆，其实它对栈变量的读写越界同样敏感，包括局部数组、结构体成员、甚至 std::array 的 operator[]（未开启 std::array::at() 时）。但要注意：
- 栈越界检测依赖编译器生成的“红区”（redzone），大小有限（默认 128 字节左右），所以极大数组的越界可能逃逸检测
- 函数参数如果是数组退化为指针（如
void f(int* a)），ASan 无法知道原长度，也就无法判断是否越界——这时得靠std::span或传入size_t len配合手动检查 - 示例：
int buf[4]; buf[-1] = 0;会立刻触发stack-buffer-underflow；buf[5] = 0;触发stack-buffer-overflow
Linux 下动态链接 ASan 运行时需确保 LD_LIBRARY_PATH 正确
用 -fsanitize=address 编译出的可执行文件依赖 libasan.so，系统通常不自带。若运行时报 error while loading shared libraries: libasan.so.x: cannot open shared object file，说明运行时找不到它：
立即学习“C++免费学习笔记（深入）”；
- 查路径：
g++ -print-file-name=libasan.so输出的就是编译器自带的 so 路径（如/usr/lib/gcc/x86_64-linux-gnu/11/libasan.so） - 临时解决：
export LD_LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/11:$LD_LIBRARY_PATH - 更稳方案：用
-static-libasan静态链接 ASan 运行时（但会增大二进制体积，且无法与系统级 ASan 工具链协同）
ASan 报错信息里带的地址偏移、线程 ID、内存映射状态都很真实，但别忽略它默认关闭对 malloc_usable_size 类函数的支持——如果你在自定义分配器里重度依赖这类接口，得额外加 -fsanitize=address,undefined 并仔细验证行为一致性。
