AddressSanitizer是C++中检测缓冲区溢出最实用的运行时工具，通过-fsanitize=address -g -O1编译链接即可捕获堆、栈、全局区越界读写，报错含精确地址、调用栈和偏移，无需改代码，是调试偶发崩溃与变量被意外修改的首选方案。
用 AddressSanitizer 编译时检测 buffer overflow
AddressSanitizer（ASan）是目前最实用、开箱即用的 C++ 缓冲区溢出检测工具，它能在运行时捕获堆、栈、全局区的越界读写。启用只需加一个编译选项，不需要改代码。
常见错误现象：程序偶发崩溃、输出乱码、变量值被意外修改，但 gdb 里看不出明显问题——这很可能是 ASan 能揪出来的那种“幽灵越界”。
- Clang/GCC 都支持：
g++ -fsanitize=address -g -O1（-O1是推荐的优化级，更高可能抑制部分检测） - 必须链接时也带
-fsanitize=address，否则报 undefined reference - 不要和
-fstack-protector混用，ASan 已覆盖栈溢出检测，且二者可能冲突 - 检测到问题时会打印类似
heap-buffer-overflow on address 0x60200000001c at pc 0x000000401234 bp 0x7ffd12345678 sp 0x7ffd12345670的详细信息，含地址、调用栈、越界偏移
std::vector::at() 替代 [] 做边界检查
对容器访问，[] 不检查下标，而 at() 在越界时抛 std::out_of_range 异常，适合开发/测试阶段主动暴露逻辑错误。
使用场景：你控制容器生命周期、知道访问可能越界（比如解析用户输入索引），又不想引入 ASan 或静态分析工具链。
立即学习“C++免费学习笔记（深入）”；
-
vec.at(i)比vec[i]稍慢（一次函数调用 + 条件判断），但代价远小于崩溃后调试一小时 - 注意：只对
std::vector、std::string、std::deque有效；std::array的at()同样检查，但operator[]仍是未定义行为 - 不能替代 ASan——它只查容器内内存，不查原始数组、C 风格字符串、
malloc分配的内存
静态分析工具识别潜在 memcpy/strcpy 溢出
像 strcpy(dst, src)、memcpy(dst, src, n) 这类 C 风格操作，是缓冲区溢出重灾区。Clang Static Analyzer 和 GCC 的 -fanalyzer（GCC 13+）能基于上下文推断长度是否可信。
典型误用：char buf[10]; strcpy(buf, user_input); —— 静态分析器若看到 user_input 长度不可控，会警告 buffer overflow possible。
- Clang：用
clang++ --analyze -Xanalyzer -analyzer-output=text启动分析 - GCC：
g++ -fanalyzer -Wall，配合-Wstringop-overflow=系列开关更敏感 - 局限：无法处理运行时计算的长度（如
strlen(src) + 1但没验证dst容量），这类仍需 ASan 收尾
为什么不用 std::string::c_str() 直接传给 strcat 类函数
c_str() 返回的指针指向内部只读缓冲区，且其容量不等于你分配的空间大小。直接拿它当 strcat 目标，几乎必然溢出。
错误示例：std::string s = "hello"; strcat(s.c_str(), " world"); —— c_str() 返回的是 const char*，且没有预留额外空间，strcat 会往只读内存写，触发 ASan 报 WRITE of size X at ... 或直接段错误。
- 正确做法：用
std::string自身拼接：s += " world"，或用std::vector<char></char>手动管理可写缓冲区 - 若必须用 C 接口，先确保目标缓冲区足够大，并用
snprintf/strncat等带长度限制的函数 - 这个坑特别隐蔽：编译通过、看起来运行正常，但一旦字符串变长或内存布局变化，就崩
真正难防的是那些跨函数、跨模块、长度信息在传递中丢失的越界——比如一个 int len 参数没同步更新，或者结构体填充导致 sizeof 和实际可用字节数不一致。这时候 ASan 是唯一靠谱的兜底手段，但得记得在 CI 里跑带 ASan 的测试用例，而不是只在本地试两下。
