AddressSanitizer（ASan）是最直接有效的越界访问捕获方案，通过编译期插桩实时检测heap/stack缓冲区溢出、use-after-free等错误并精确定位到源码行号；需编译时启用-fsanitize=address -g -O1且避免与TSan混用，禁用于生产环境。
用 AddressSanitizer 捕获越界访问最直接有效
AddressSanitizer（ASan）是 Clang/GCC 官方支持的内存错误检测器，能实时捕获 heap-buffer-overflow、stack-buffer-overflow、use-after-free 等问题，并打印出完整调用栈。它不是运行时库替换，而是编译期插桩，开销约 2×，但足够用于开发和测试阶段。
启用方式极简：
g++ -fsanitize=address -g -O1 your_code.cpp -o your_program
注意三点：
-
-O1是推荐优化等级，-O2及以上可能因优化导致行号错位或漏报 -
-g必须带上，否则 ASan 报错时无法显示源码位置 - 不要混用
-fsanitize=address和-fsanitize=thread，二者互斥
运行时报错示例：
立即学习“C++免费学习笔记（深入）”；
==12345==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000003c at pc 0x0000004012ab bp 0x7ffeedb8a9d0 sp 0x7ffeedb8a9c8
READ of size 4 at 0x60200000003c thread T0
#0 0x4012aa in main /tmp/test.cpp:5
这行 /tmp/test.cpp:5 就是越界读发生的位置，无需额外工具即可定位。
ASan 无法覆盖的场景：生产环境无 ASan 时怎么办
ASan 不能上生产——它会增大二进制体积、消耗额外内存（约 2×）、且不兼容某些底层操作（如自定义 malloc、信号处理干扰）。此时需靠轻量级运行时防护 + 主动上报机制。
可行路径是：在关键容器（如 std::vector、自定义 buffer）中启用边界检查，并统一接入异常收集通道：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 对
std::vector，避免裸用operator[]，改用at()——它会在越界时抛std::out_of_range - 对原始数组或
char*缓冲区，封装一层带范围校验的访问函数，例如：safe_read(buf, len, offset)，内部先判断offset + size - 所有越界路径统一 throw 或调用
report_memory_violation("read", addr, caller)，再由全局std::set_terminate或信号处理器（SIGSEGV）兜底捕获
注意：SIGSEGV 处理器里不能调用 STL 容器、malloc、printf 等非异步信号安全函数，否则可能死锁或二次崩溃；建议只做寄存器快照 + 写入 mmap 的共享日志页。
回溯调用栈需要符号与帧指针配合
没有调试符号（-g）或编译时禁用了帧指针（-fomit-frame-pointer），backtrace() 和 ASan 的栈展开都会失效或截断。
确保以下配置同时生效：
- 编译加
-g（生成 DWARF 符号） - 避免
-fomit-frame-pointer（GCC 默认在-O2启用，需显式加-fno-omit-frame-pointer） - 链接时保留符号：不加
-Wl,--strip-all或-s
若必须 strip 生产包，可提前导出 .debug 文件分离存储，配合 addr2line -e your_binary -f -C 0x4012aa 离线解析地址。
上报机制要绕过 libc 内存分配，防止雪崩
越界常发生在堆损坏后，此时 malloc、new、甚至 std::string 构造都可能失败。上报逻辑必须使用预分配内存或 mmap 的固定页。
典型做法：
- 启动时用
mmap(MAP_ANONYMOUS | MAP_PRIVATE, 4096)预留一页作为“紧急日志缓冲区” - 上报函数只做 memcpy + 原子写入，不格式化、不分配、不调用 IO
- 另起守护进程轮询该页，发现新记录就序列化为 JSON 上报，并清空标记
这种设计下，即使主程序堆已腐坏，只要页未被 munmap，上报仍能执行。而多数 crash reporter（如 breakpad）默认依赖 malloc，反而在此类场景下不可靠。
越界问题的根因往往不在触发点，而在更早的释放/重用/计算错误；监控只是第一道防线，真正要盯住的是 ASan 报告里的“allocated here”和“freed here”上下文——那里才是修复入口。
