vector::at() 在越界时抛 std::out_of_range 异常，operator[] 不检查越界、行为未定义；前者有运行时开销，后者零成本但危险；调试模式下可启用 operator[] 边界检查。
![c++ vector at和[]区别 c++数组越界检查机制分析【安全】](https://img.php.cn/upload/article/001/431/639/176948212617684.jpg)
vector::at() 会抛异常，operator[] 不检查越界
vector::at() 在索引超出 size() 范围时，抛出 std::out_of_range 异常；而 operator[] 完全不检查，行为是未定义的（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 ），用 <code>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 有时也抓不到（比如只读越界未触发保护页）。
立即学习“C++免费学习笔记（深入）”；
- 生产环境禁用 ASan 后，
at()是唯一可依赖的运行时防护手段，但它不能替代逻辑校验 - 对关键索引（如配置项、协议字段偏移），建议在首次使用前断言：
assert(i ，比异常更轻量，且 release 版本可通过 <code>NDEBUG移除 - 注意迭代器失效和 size 变化：即使用了
at()，若在循环中push_back()导致size()增长，原索引可能仍合法；但若erase()或clear()后继续用旧索引，at()就会如期抛异常——这反而是好事
