17370845950

vector::at() 在越界时抛 std::out_of_range 异常，operator[] 不检查越界、行为未定义；前者有运行时开销，后者零成本但危险；调试模式下可启用 operator[] 边界检查。

vector::at() 会抛异常，operator[] 不检查越界

vector::at() 在索引超出 size() 范围时，抛出 std::out_of_range 异常；而 operato

r[] 完全不检查，行为是未定义的（UB）。这意味着用 operator[] 访问 v[100] 时，哪怕 v.size() == 5，编译器不会报错、运行时也不一定崩溃——可能读到垃圾值，也可能意外改写相邻内存，甚至在某些优化级别下被编译器直接优化掉整个访问。

• 调试阶段开 -D_GLIBCXX_DEBUG（GCC）或启用 MSVC 的 _ITERATOR_DEBUG_LEVEL=2，能让 operator[] 也带检查，但这仅限 debug 构建，不可依赖
• at() 的开销略高：每次调用都需比较索引与 size()，并准备异常处理路径；operator[] 是纯指针偏移，零成本抽象
• 若逻辑上已确保索引合法（如循环 for (size_t i = 0; i ），用 operator[] 更自然；若索引来自用户输入、文件解析或计算结果，优先用 at()

原生 C++ 数组没有越界检查机制

无论是栈上数组 int a[10]; 还是堆上 new int[10]，C++ 标准完全不强制任何越界检查。访问 a[15] 或 p[20] 就是未定义行为——不报错、不中断、不警告（除非静态分析工具介入）。编译器可能生成看似“正常”的代码，但结果不可预测。

• Clang 的 -fsanitize=address（ASan）和 GCC 的同名选项可在运行时捕获大部分越界读写，但会显著拖慢执行、增加内存占用，仅用于测试
• 静态分析工具（如 Clang Static Analyzer、PVS-Studio）能在编译期发现部分明显越界，但对动态计算索引束手无策
• 不要试图用 sizeof(a)/sizeof(a[0]) 来“安全”遍历函数参数里的数组——传入函数后，它退化为指针，sizeof 失效

std::array 的 operator[] 同样不检查，但 at() 有

std::array 是固定大小的容器，其 operator[] 和原生数组一样不检查边界；但它的 at() 成员函数提供和 vector::at() 一致的异常检查语义。区别在于：std::array::at() 的检查在编译期已知大小，部分优化器可能更激进地内联或消除冗余判断，但标准不保证。

• 对栈上小数组且索引来源可信时，std::array + operator[] 是零开销替代原生数组的安全升级
• 若需统一处理“可能越界”的场景，别混用 operator[] 和 at()；同一段逻辑里保持检查策略一致，避免漏掉某处
• std::array 没有 data() 以外的动态分配，所以 at() 异常开销比 vector 略低，但差异微乎其微

越界问题最危险的不是崩溃，而是静默错误

真正棘手的不是程序立刻 segfault，而是越界写入恰好覆盖了 nearby 变量、虚表指针或 malloc 元数据，导致几秒甚至几分钟后才崩，且崩溃点与问题源头毫无关联。这类 bug 在多线程环境下更难复现，ASan 有时也抓不到（比如只读越界未触发保护页）。

• 生产环境禁用 ASan 后，at() 是唯一可依赖的运行时防护手段，但它不能替代逻辑校验
• 对关键索引（如配置项、协议字段偏移），建议在首次使用前断言：assert(i ，比异常更轻量，且 release 版本可通过 NDEBUG 移除
• 注意迭代器失效和 size 变化：即使用了 at()，若在循环中 push_back() 导致 size() 增长，原索引可能仍合法；但若 erase() 或 clear() 后继续用旧索引，at() 就会如期抛异常——这反而是好事