C++数组越界访问不崩溃但行为不可预测：operator[]和原生下标无边界检查，越界读得垃圾值，越界写覆写栈数据，导致逻辑错乱、延迟崩溃或看似正常；std::vector::at()抛异常而operator[]不检查；栈溢出可劫持控制流；看似安全的长度判断可能因整数溢出等失效。
数组越界访问不会立即崩溃，但行为完全不可预测
在 C++ 中，operator[] 和原生数组下标访问（如 a[i]）**不做边界检查**。越界读可能拿到任意内存中的垃圾值，越界写则直接覆写相邻栈变量、返回地址、函数指针或栈帧元数据。结果不是“报错”，而是：程序可能继续运行，但逻辑错乱、输出异常、后续某个无关位置突然崩溃（延迟崩溃），甚至看似正常——直到上线后在特定输入下触发严重故障。
常见现象包括：
-
std::vector::at()会抛std::out_of_range，但std::vector::operator[]同样不检查 - 越界读取可能恰好命中未初始化的栈内存，表现为随机数或零值
- 覆盖邻近
bool或int变量时，导致条件判断翻转、循环次数突变 - 在开启 ASLR/Stack Canary 的现代系统中，崩溃可能更晚出现，但漏洞依然存在
缓冲区溢出如何被用于劫持控制流
经典栈溢出攻击依赖两个关键事实：函数局部数组通常分配在栈上；函数返回地址也存在栈上，且与局部变量物理相邻。当用 strcpy、gets 或裸 for 循环向固定大小数组写入超长数据时，多余字节就会一路覆盖后面的栈内容。
攻击者精心构造输入，使溢出数据覆盖返回地址为指向自己注入代码（shellcode）的地址，或跳转到 libc 中已有函数（如 system）的地址（ROP 攻击）。例如：
立即学习“C++免费学习笔记（深入）”；
char buf[64]; gets(buf); // 危险！无长度限制
若输入 72 字节，前 64 字节填满 buf，接下来 4–8 字节就可能覆盖保存的 ebp 和 ret addr。现代编译器默认启用 -fstack-protector，会在栈上插入 canary 值并在函数返回前校验，但绕过方法（如泄露 canary）仍存在。
哪些写法看似安全实则危险
很多开发者误以为加了长度判断就万事大吉，但整数溢出、符号转换、类型不匹配会让防护形同虚设：
-
int len = recv(sock, buf, sizeof(buf), 0); if (len > sizeof(buf)) return; memcpy(dst, buf, len);——len是有符号 int，若网络传回负值，len > sizeof(buf)永远为假，但memcpy会按极大正数解释该负值（二进制补码） -
size_t n = strlen(src); char dst[n+1]; strcpy(dst, src);—— 若src不以'\0'结尾，strlen行为未定义，n可能极大，导致栈分配失败或静默截断 std::array<int> a; for (int i = 0; i —— <code>i 导致最后一次访问 <code>a[10]，越界
真正有效的缓解手段有哪些
靠人眼审查无法杜绝这类问题。必须结合工具链和编码习惯：
- 编译时加
-D_GLIBCXX_DEBUG（libstdc++ 调试模式），让std::vector::operator[]等容器操作自动检查 - 启用 AddressSanitizer：
g++ -fsanitize=address -g，越界访问会在运行时报明确错误，含堆栈和越界偏移 - 禁用不安全函数：用
strncpy替代strcpy，但注意它不保证目标以'\0'结尾；更推荐std::string或std::vector - 对所有外部输入做严格长度验证，且验证逻辑必须使用与目标缓冲区一致的无符号类型（如
size_t）
最易被忽略的一点是：即使用了 std::vector，如果手动计算下标（如 v[i + offset]）且没校验 i + offset ，同样越界——容器安全只在你调用它的接口时生效，不保护你的算术逻辑。
