std::out_of_range由at()等显式边界检查方法抛出，如vector::at、string::at、deque::at及string::substr（pos>size()时）；operator[]不抛该异常而是导致未定义行为。
std::out_of_range 不是“用来处理”越界异常的工具，而是 被抛出的异常类型；真正负责检测和抛出它的，是容器自带的带边界检查的访问接口（比如 at()）。
哪些容器方法会抛出 std::out_of_range？
不是所有访问操作都会触发它。只有显式启用边界检查的方法才会：
-
std::vector::at(size_t n)、std::string::at(size_t pos)、std::deque::at()等 —— 这些函数在n >= size()时抛出std::out_of_range -
std::basic_string::substr(size_t pos, size_t len)在pos > size()时也抛std::out_of_range（注意：不是pos >= size()，pos == size()是合法的，返回空串） -
operator[]从不抛std::out_of_range—— 它是未定义行为（UB），哪怕越界也不会报错，调试时极难发现
如何正确捕获并处理 std::out_of_range？
必须用 try/catch 包裹可能抛出该异常的调用，且 catch 类型要精确匹配或可向上转型：
std::vectorv = {1, 2, 3}; try { int x = v.at(5); // 这里抛 std::out_of_range } catch (const std::out_of_range& e) { std::cerr << "Index out of range: " << e.what() << '\n'; // 可以 fallback、日志、重试等 }
- 不要写
catch (...)吞掉所有异常 —— 会掩盖本该暴露的逻辑错误 - 不要
catch (std::exception)后不做区分 ——std::out_of_range和std::bad_alloc的修复策略完全不同 - 注意
e.what()返回的是实现定义的字符串，通常含索引和容器大小信息（如vector::_M_range_check: __n (which is 5) >= this->size() (which is 3)），但不可解析依赖
性能与调试权衡：at() vs operator[]
at() 带检查，operator[] 不带 —— 这不是风格选择，而是场景选择：
立即学习“C++免费学习笔记（深入）”；
- 用户输入、配置文件解析、网络数据解析等外部不可信索引 → 必须用
at() - 内部循环计数器（如
for (size_t i = 0; i ）→ 可用operator[]，避免重复检查 - Release 模式下
at()的检查开销很小（一次比较 + 分支），但比operator[]多一次条件跳转；不过比起越界导致的崩溃或数据损坏，这点开销几乎可以忽略 - Clang/GCC 的
-D_GLIBCXX_DEBUG或 MSVC 的_ITERATOR_DEBUG_LEVEL=2可让operator[]也做调试检查，但仅限 debug 构建
最容易被忽略的一点：std::out_of_range 只覆盖“索引超界”，不覆盖“迭代器失效”或“空容器调用 front()/back()”。后者抛的是 std::logic_error 子类（如 std::domain_error）或直接 UB —— 它们需要各自独立的防御逻辑。
