4. QVector越界：at()与operator[]的区别、越界访问的调试方法

说实话，QVector越界这个问题，我几乎在每个项目里都见过。新手踩，老手偶尔也踩。我自己就曾经在一个图像处理模块里，因为一个越界访问，排查了整整一个下午。最后发现只是把at()和operator[]搞混了。

今天咱们就把这个坑彻底填平。

4.1 at() 和 operator[] 到底有什么区别？

先看一个最简单的例子：

QVector<int> vec = {10, 20, 30};
int a = vec[5];      // 危险！
int b = vec.at(5);   // 会怎样？

嗯，这里要注意。两个写法都能编译通过，但行为完全不同。

特性	operator[]	at()
越界检查	无（Release模式）	有（始终检查）
越界行为	未定义行为（可能崩溃，也可能不崩溃）	抛出 std::out_of_range 异常
性能	略快（无检查开销）	略慢（有检查开销）
返回值	返回引用	返回 const 引用

说白了，operator[] 是裸奔，at() 是系了安全带。

4.2 为什么 operator[] 不检查越界？

你想想看，Qt 的设计哲学是「你不该为不需要的东西付费」。在性能敏感的循环里，每次访问都检查索引，确实会拖慢速度。所以 operator[] 默认不做检查——它相信你写的索引是对的。

但问题是，我们经常犯错。

我个人习惯是：

• 循环遍历：用 operator[]，因为索引可控
• 外部传入的索引：用 at()，或者自己先判断 index < size()

4.3 越界访问的调试方法

越界访问最恶心的地方在于——它不一定会立刻崩溃。可能跑了几万次循环后，突然崩在一个莫名其妙的地方。我在项目中遇到过这种情况，当时差点把键盘砸了。

后来我总结了一套调试流程：

方法一：启用 Qt 的越界检查（Debug 模式）

Qt 在 Debug 模式下，operator[] 其实也会做检查。如果你用的是 MSVC 或 GCC，可以加这个宏：

#define QT_DEBUG
// 或者直接在 .pro 文件里加：
// CONFIG += debug

这样 operator[] 越界时，Qt 会输出类似这样的警告：

ASSERT failure in QVector<T>::operator[]: "index out of range", ...

嗯，看到这个就说明你找到问题了。

方法二：手动加断言

如果你不想依赖 Qt 的检查，可以自己加：

int index = getIndexFromSomewhere();
Q_ASSERT(index >= 0 && index < vec.size());
int value = vec[index];

Q_ASSERT 在 Release 模式下会被自动移除，不影响性能。

方法三：使用 at() 临时替换

我建议你调试时，先把所有 operator[] 临时换成 at()。这样越界时会直接抛异常，你就能在调用栈里看到是谁传了错误的索引。

// 调试时
int value = vec.at(index);

// 发布时再改回来
// int value = vec[index];

4.4 一个典型的越界场景

来看一个我实际修过的 bug：

void processData(const QVector<int>& data) {
    for (int i = 0; i <= data.size(); ++i) {  // 注意：这里是 <= 不是 <
        qDebug() << data[i];  // 最后一次越界！
    }
}

这种错误太常见了。循环条件写成了 <=，结果最后一次访问 data[size()]，直接越界。

我曾经在一个数据处理流水线里，就因为少写了一个等号，导致线上服务偶尔崩溃。排查了三天，最后发现是这里的问题。嗯，从那以后我写循环都会多看一眼条件。

4.5 避坑指南

4.6 知识体系图

下面这张图帮你理清今天讲的核心逻辑：

这张图把今天的内容串起来了。左边是两种访问方式的对比，右边是三种调试手段。你调试时，可以按这个思路一步步排查。

好了，关于 QVector 越界的问题，今天就聊到这儿。记住一句话：能用 at() 就用 at()，不能用的地方，自己做好检查。这样能省下不少调试时间。