崩溃点常非越界发生处，而是被破坏内存被读写时才暴露；Access violation reading/writing location 是Windows下CPU硬件级内存保护触发的SEGV错误，需结合ASan等工具定位真实越界源码行。
崩溃点往往不是越界发生的位置，而是被踩坏的内存被读写时才暴露——所以不能只盯着报错行。
Access violation reading/writing location 是什么信号
这是 Windows 下 Visual Studio 调试器捕获到的 SEGV 类错误，本质是 CPU 硬件级内存保护触发。reading location 0x0000000000000000 表示你解引用了空指针；writing location 0x00007FF6C21A3F2E 则大概率是数组越界写入、堆缓冲区溢出或释放后使用（UAF）。
关键要分清：读越界常伴随垃圾值、逻辑错乱；写越界更危险，会直接破坏相邻变量、vtable、栈返回地址，导致几秒后才崩在完全无关的函数里。
- 不要只看崩溃弹窗里的地址——它只是“受害者地址”，真正肇事的是上一条
arr[idx]或p[i] - 调用堆栈里最上面几帧如果全是系统 DLL 或优化掉的内联函数，说明原始越界点已被覆盖，得靠工具回溯
- 如果崩溃发生在
std::vector::operator[]里，但你没用at()，那大概率是你自己绕过了边界检查
用 AddressSanitizer 快速定位越界源码行
ASan 不是“试试看”的可选工具，而是 C++ 开发中必须开启的编译期守门员。它能在越界发生的那一行就中断，并打出完整上下文。
立即学习“C++免费学习笔记（深入）”；
- Clang/GCC 编译加
-fsanitize=address -g -O1（注意必须用-O1，-O2可能删掉插桩逻辑） - 运行时报错会明确标出类型：
heap-buffer-overflow（new/malloc 分配的数组）、stack-buffer-overflow（局部数组）、global-buffer-overflow（全局数组） - 输出里
READ of size 4 at 0x60200000001c告诉你访问了哪块内存、读了多少字节；下面的调用栈精确到 .cpp 行号 - 对
struct { int arr[10]; } s;这类内嵌数组，ASan 有时不报——此时需配合valgrind --tool=memcheck补充验证
手动检查常见越界模式
工具再好也替代不了代码层面的防御意识。以下写法在真实项目中高频翻车：
for (int i = 0; i —— 错在用了 <code>，正确是 <code>i-
int buf[BUF_LEN]; int idx = get_from_uart(); buf[idx] = 1;—— 外部输入未校验，必须加if (idx >= 0 && idx -
std::vector<int> v(5); v[10] = 42;</int>——operator[]在 Release 模式下不检查，要用v.at(10)主动抛异常 -
char* p = new char[100]; p[100] = '\0';—— 动态数组长度是 100，合法下标是[0, 99]，p[100]是越界写
为什么调试器单步跟不到越界点
因为 C/C++ 的数组访问是裸指针运算，不带任何运行时检查。CPU 执行 mov eax, [rbp-0x20+rdi*4] 这条指令时，只要地址在进程虚拟内存范围内，就不会触发异常——哪怕那个地址属于另一个变量的内存块。
真正崩溃往往发生在后续：比如越界写把某个 std::string 的 _M_length 字段改成了极大值，之后调用 .c_str() 时尝试分配 GB 级内存而失败；或者踩坏了栈上的返回地址，函数返回时跳到非法指令地址。
这种延迟崩溃意味着：你不能依赖“崩溃在哪就修哪”，而必须对所有外部输入、循环索引、指针偏移做显式校验，再配合 ASan 在开发阶段把越界扼杀在编译后、运行前。
