operator[] 不检查越界是设计使然，它直接指针偏移实现零开销；at() 是唯一标准规定带边界检查的成员函数，越界时抛出 std::out_of_range 异常。
![c++ vector方括号越界检查 c++ operator[]与at性能安全性对比【坑点】](https://img.php.cn/upload/article/001/431/639/176983458245628.jpg)
operator[] 不检查越界，这是设计使然
operator[] 在 C++ 标准中明确要求不执行边界检查，它只是对底层指针做偏移访问。这意味着 v[i] 和 &v[0] + i 在行为上几乎等价，零开销是它的核心契约。
常见错误现象：在调试模式下没报错，发布后偶发崩溃或读到垃圾值；用 valgrind 或 ASan 检测时才暴露非法内存访问。
- Release 模式下
v[100]访问长度为 10 的vector—— 行为未定义，不抛异常、不中断、不提示 - 即使开了
-D_GLIBCXX_DEBUG（libstdc++ 调试模式），operator[]仍不检查 —— 这点很多人误以为会检查 - 某些 IDE 或 sanitizer 插件可能拦截并告警，但这不是语言/标准库保证的行为
at() 是唯一标准规定的带检查访问方式
at() 是 vector 唯一承诺做运行时边界检查的成员函数，越界时抛出 std::out_of_range 异常。
使用场景：你明确需要“安全但可接受异常开销”的场合，比如用户输入索引、配置文件解析、脚本绑定层等不可信数据源驱动的访问。
立即学习“C++免费学习笔记（深入）”；
- 调用
v.at(i)会先比较i ，失败则构造 <code>std::out_of_range并throw - 异常开销实际不小：栈展开、异常对象构造、RTTI 查找 —— 在 tight loop 中明显拖慢性能
- Clang/GCC 在开启
-O2且i为编译期常量时，可能把检查优化掉，但别依赖这个
如何让 operator[] 也带检查（开发期）
标准库不提供，但你可以用编译器扩展或构建时开关启用调试检查 —— 注意：这仅作用于开发阶段，不影响 Release 行为。
libstdc++ 用户可加编译选项：-D_GLIBCXX_DEBUG，此时 operator[] 仍不检查，但 at() 会额外校验迭代器有效性；真正起作用的是整个容器调试模式（如 vector::begin() 被篡改后访问会 abort）。
- MSVC 用户可用
_ITERATOR_DEBUG_LEVEL=2（默认开启），此时operator[]在 Debug 模式下会触发断言（_STL_VERIFY） - 更通用的做法：自己封装一个
safe_vector，重载operator[]调用at()，但注意命名要清晰，避免误导协作者 - 静态分析工具如 Clang Static Analyzer 或 PVS-Studio 可捕获部分明显越界，但无法覆盖所有动态路径
性能差异真实有多大？别猜，测一下
差别不在“函数调用本身”，而在是否引入分支判断和异常路径。现代 CPU 对 predictably bounded at() 分支预测很好，但一旦越界，代价就从几 cycle 飙升到 thousands。
// 典型微基准（GCC 12, -O2） for (int i = 0; i < v.size(); ++i) sum += v[i]; // ~1.2 ns/iter for (int i = 0; i < v.size(); ++i) sum += v.at(i); // ~1.8 ns/iter（无越界） for (int i = 0; i <= v.size(); ++i) sum += v.at(i); // 第一次越界后直接卡住或崩溃
- 在 size 已知且循环变量受控时，
operator[]几乎无成本，at()多一次条件跳转 - 如果循环上界来自外部（如
int n = get_user_input(); for(int i=0; i<n v.at>），那每次都要检查</n> - ASan（AddressSanitizer）会使所有数组访问变慢 2–3 倍，但它能帮你揪出
operator[]的越界 —— 开发期值得开
at()，而是混用两种风格又没写清楚前提条件：比如函数文档说“索引必须有效”，但调用方传了 size()，而实现里用了 operator[] —— 这种隐式契约比裸指针还难 debug。 
