死磕数组：底层原理、高频操作与工程避坑实战

今天进入算法学习的第二天，计划是死磕数组。老实说，最开始我觉得数组没什么好学的，任何一个写过代码的人都能用数组存数据、遍历数据。但当我真要认真整理的时候，发现数组里能挖的细节实在是太多了：搜索热度上成片的问题，像C++字符串数组初始化、二维数组指针、数组去重、双指针合并有序数组、甚至树状数组上二分，全都绕不开数组这个概念。这一天的目标就不是单纯过一遍语法，而是把数组相关的高频场景从底层原理到实际应用完整捋一遍，解决“我好像会，但真写起来容易翻车”这类问题。

这篇内容适合正准备系统学算法的新手，也适合做了几年业务开发但想补基本功的工程师，尤其适合经常在C++里和数组较劲的朋友。我不会只堆理论，后面会把我当天练的代码、运行结果、踩到的坑全部放出来，包含可以直接抄的写法。

1. 先别急着写题，我在理解数组的底层结构上花了很多时间

1.1 为什么数组的读操作能到O(1)

很多人对O(1)读取烂熟于心，但未必认真想过这个结论从何而来。数组的底层存储是一段连续的内存空间，数组名本质上是这段内存的首地址。我们访问第i个元素时，实际上执行的是“首地址 + i × 每个元素占用的字节数”，这是典型的数学计算：一次加法和一次乘法，CPU执行起来几乎不耗时。这就是随机访问能在常数时间内完成的原因。

用生活里的例子来对比就很好理解。你去图书馆找一本书，书架每一层都有固定编号和固定格子，管理员说“第5排第3格”，你直接走过去就能拿到，不需要一本一本地翻。链表就不是这个概念了，它的节点散落在内存各个角落，想找第5个节点必须从第1个一路next过去，时间复杂度O(n)。所以数组的O(1)读操作，是算法题里最底层的优势，很多优化策略本质都是把它利用起来。

这里有个我早期没注意的细节：数组下标从0开始，不仅是语言的习惯，也跟寻址公式直接相关。如果从1开始，访问第i个元素就得写“首地址 + (i - 1) × 字节数”，每一次访问都多一次减法运算。从0开始可以让CPU少算一次，虽然单次看不出来，但大规模高频访问时差别是能测出来的。这就是为什么大多数语言的数组下标都从0开始。

1.2 连续内存带来的隐患：越界问题

连续内存带来高效访问的同时，也带来了一个麻烦：访问越界时，编译器通常不会主动告诉你。你申请了长度为5的数组，但写了一个arr[5]甚至arr[100]，C++不会像Java那样抛异常，而是直接按照地址计算公式访问内存，这个地址上到底放着什么数据，完全是未知的。可能读到垃圾值，可能把别的变量的值改掉，也可能程序运行几小时后才崩溃，排查起来非常痛苦。

我在初期练习二分查找的时候就踩过这种坑，某个边界情况算出来的下标刚好越界，程序运行结果时对时错，后来加了断言才发现。所以在自己写的代码里，涉及到数组下标的地方都要养成检查边界的习惯，尤其是用循环遍历时，终止条件里的<和<=到底用哪个，必须先想清楚，不能靠瞎试。

2. 数组操作的时间成本，这是我今天的实测笔记

2.1 遍历与查找：从普通遍历到二分查找

平时最常见的操作应该是遍历，所有元素过一遍，时间复杂度O(n)，这个没太多可说的。查找操作就需要分情况讨论了。如果数组是无序的，想确认一个元素在不在里面，只能从头遍历到尾，复杂度O(n)。如果数组有序，就可以用二分查找把时间复杂度降到O(log n)。

这里我把不同查找方式的定位过程整理成了对比表，方便后续记忆：

二分查找能写的代码并不长，但真正写得完全正确的人并不多。经典的区间写法里有左闭右闭[left, right]和左闭右开[left, right)两种，混着用最容易出错。我在后面的实操小节里会完整写一遍二分查找的代码，这里先把核心结论说清楚：一般来说，如果选择左闭右闭区间，循环条件就用left <= right；如果选择左闭右开区间，循环条件就用left < right。边界变动也要配套，不能左边用闭区间、右边用开区间，自己都没定清楚规则，代码自然没办法稳定正确。

2.2 插入与删除为什么贵

数组在指定位置插入元素时，实际上要先把插入位置后面的所有元素整体往后挪一格，再在空出来的位置上赋值。删除同理，要把后面的元素一个一个往前覆盖。这两个操作的时间复杂度都是O(n)。如果频繁在数组中间插入或删除，代价会很高，这时候就该考虑用链表来替代了。

以前我总觉得“反正数据量小，性能无所谓”，直到自己写了一个循环里反复往vector中间insert的代码，几万条数据跑了快一分钟才反应过来，逻辑上没错，但性能差到离谱。用数组的基本原则可以总结成一句话：查多改少用数组，改多查少用链表。数组和链表不是对立面，而是根据操作频率来选择的工具。

有一个实用的小技巧值得专门提一下：如果需要从数组中删除多个元素，但要求保持原有相对顺序，不要每删一个就元素前移一次，那样复杂度可能到O(n²)。更好的做法是使用双指针，一个指针负责遍历原数组，另一个指针指向新数组尾部的位置，遇到不需要删除的元素就复制过来。整个过程只需要一次遍历，时间复杂度O(n)，这是很多高频面试题的优化基础。

2.3 把常用数组方法拉出来对比：排序、去重、转字符串

在学习过程中，我搜索热度里“数组方法”“数组转字符串”“数组去重”这些关键词出现的频率很高。说明不管是做前端还是做服务端，数组的日常加工都是刚需。这里我拉了一张对比表，把不同语言里常用数组方法列了一下：

结合这张表想解释一个问题：为什么数组需要那么多方法？因为数组本身是“最基础的数据容器”，实际项目里没有谁会拿数组保存原始数据直接用，总要经过各种加工，排序后可能才好展示，去重后统计才准确，转成字符串才能传给接口。每种语言在设计时都给数组配了对应的工具，但它们底层往往都对应着经典的算法，比如排序就是快速排序或归并排序，去重本质上借助了哈希结构或排序。

3. 三类高频数组算法思路，今天直接实验验证

3.1 二分查找：从代码层面吃透边界条件

二分查找的应用范围远比我之前想的大。有序数组里找目标值是最基本的场景，但很多复杂问题只要能把数据处理成有序的形态，就能套用二分思路来降低复杂度。下面给出一个我实测无误的C++版本，选择的是左闭右闭区间写法：

cpp复制int binarySearch(const vector<int>& nums, int target) {
    int left = 0;
    int right = nums.size() - 1;
    while (left <= right) {
        int mid = left + (right - left) / 2;
        if (nums[mid] == target) {
            return mid;
        } else if (nums[mid] < target) {
            left = mid + 1;
        } else {
            right = mid - 1;
        }
    }
    return -1;
}

这里有两个容易出错的细节。第一，mid的写法建议用left + (right - left) / 2，不要用(left + right) / 2，原因是left + right在整形变量接近上限时可能溢出，虽然这只是理论风险，但习惯早点养成没有坏处。第二，当nums[mid]不等于target时，区间缩小一定要排除掉mid本身，所以left更新为mid + 1或right更新为mid - 1。如果不做这一步，某些情况下可能陷入死循环。

搜索热词里出现的“树状数组上二分”，其实是二分思想在另一种结构上的应用。树状数组支持单点更新和前缀和查询，而二分可以帮助我们在前缀和上快速定位“第一个让前缀和大于等于某个值”的位置，这种场景在处理带权选择、排名问题时很常见。虽然我当天没有展开到那种程度，但从数组的二分开始理解前缀和的二分，会顺畅很多。

3.2 双指针：解决数组操作问题的利器

双指针不是某一种具体的算法，而是一种处理数组问题的编程技巧。它充分利用了数组连续且有序的特点，设置两个指针从不同方向或不同速度移动，把原本O(n²)的遍历优化到O(n)。最典型的应用就是“有序数组合并”和“移除指定元素”。

合并有序数组时，最直接的思路是把两个数组复制到新数组里，整体排序，但排序引入了不必要的O(n log n)。双指针的做法是，分别用两个下标指向两个有序数组的开头，每次比较当前位置对应的值，把较小的放入结果数组，同时移动对应指针，直到某一个数组被遍历完，再把另一个数组剩下的元素全部追加进去。整个过程只遍历了一遍，时间复杂度降到了O(n)。

搜索热度里出现的“java双指针合并有序数组”也印证了这个场景是面试常客。需要注意的是，合并前一定要确认两个输入数组确实有序，否则整个双指针的前提都不成立。我自己写合并时还有一次把条件写反了，结果输出的是一个逆序数组，最后还是靠打印中间结果才定位到问题。数组问题里一旦结果不对，第一反应应该是把每次关键循环的中间变量打出来看。

3.3 滑动窗口：连续子数组问题的万能钥匙

如果说双指针是两个点同时推进，那滑动窗口就是在数组上维护一段连续的区间。区间左边界和右边界都只向一个方向移动，所以整体复杂度依然能保持在O(n)。凡是遇到“最长连续子串”“最短覆盖子串”“连续元素和大于某个值的最小区间”这类问题，优先想到滑动窗口准没错。

以“长度最小的子数组”为例，已知正整数数组nums和目标值target，要求找出连续子数组和大于等于target的最短长度。暴力法是枚举每个起点，再往后逐个累加，复杂度O(n²)。滑动窗口的思路则是让右指针不断向右扩展，窗口内元素和达到目标后，记录当前窗口长度，然后把左指针向右收缩，直到窗口内元素和小于目标，每一次移动都只做一次加法和一次减法。我上午写了暴力版，又改成滑动窗口版，从结果看正确性一致，但几万条数据的耗时差距非常明显。

这类题目理解起来不困难，难点在于左右边界的更新时机，以及目标值的判断条件。我建议练手时先在草稿纸上画出窗口一步步滑动的过程，再动手写代码，会比直接凭感觉写顺畅得多。

4. C++ 与真实项目中的数组老坑位

4.1 字符串数组初始化，看着简单其实有细节

搜索词里“C++字符串数组初始化”常年有人搜，不是没有原因的。C++里表示字符串有两种常见方式：一种是char数组，一种是std::string对象。很多人先学C，习惯用char数组，结果在初始化时就把自己绕晕了。

基于char的二维数组初始化是这样的：

cpp复制char names[2][16] = {"alice", "bob"};

这里第二个维度16表示每个名字最多可以存放15个字符加一个末尾的空字符，超了就会报错或数据截断。而stl的std::string版本是：

cpp复制string names[] = {"alice", "bob"};

不需要关心长度，使用方便很多。在现代C++项目里，我强烈建议优先使用std::string而不是char数组，只有做底层协议解析或需要严格控制内存分配的场景，才回去操作char数组。

另外一个常见的错误是混淆char数组和char指针数组。char* arr[]可以存放多个字符串的首地址，但它本身只存了指针，字符串常量的具体内容不在这个数组里。这样设计能省内存，但要注意字符串有没有可写权限，如果尝试修改字符串常量，行为未定义。这些基本概念不了解，写代码就是埋雷。

4.2 二维数组与指针数组，别把三层关系搞混

二维数组和指针数组看起来都能模拟矩阵，实现上是完全不同的。二维数组在内存中是连续的一块区域，是“上一行结束后紧接着下一行”的排布；指针数组则是先有一个数组，数组里每个元素存储一个地址，这些地址指向的可能是内存中完全不相邻的区域。

我用一个表来说明多维数组和指针在多维上的组合关系：

C++里面用二维数组传参格外麻烦。函数参数写成int a[][4]时，第二维必须显式写出来，因为编译器要根据第二维的步长来计算地址偏移。如果写成int**，看起来是二维的，实际上和int a[][4]并不等价。常见做法是把二维数组转成int*指针，自己用row * 列数 + col来手动计算下标。

用QDebug调试二维数组时候也有不少人对设置比较头疼，实际上在Qt开发中，如果你把二维数组声明成了普通内置数组，默认调试器表达式里想查看整个数组内容，需要自己增加表达式，比如arrayName@12，表示查看数组起始位置往后共12个元素。这类工具类的问题虽然不影响线上功能，但调试时找不到数据，真的很浪费时间。

4.3 数组作为函数参数时，降级成指针

这是我当天最有价值的认知刷新之一：数组名在赋值和传参时并不等于整个数组，而是退化为指向首元素的指针。这种机制叫“数组退化”，在C和C++中都会发生。

cpp复制void printArray(int arr[]) {
    cout << sizeof(arr) / sizeof(arr[0]) << endl;
}

上面的代码里的sizeof(arr)的结果出乎很多初次接触的人的意料，它不会得到数组总字节数，而是得到指针的大小，通常是8字节（64位系统）。除以sizeof(arr[0])得到的结果自然也不对，并不是我们期望的元素个数。这是C++里一个经典误区。想正确处理数组参数，必须把数组长度一起传进去，或者使用std::vector这类容器，因为vector的size方法能可靠返回元素个数。

在实际工程中，凡是函数需要接收数组并做遍历的，我推荐直接传std::vector或者std::span。在C语言风格的接口里，无法避免时始终遵循长度参数显式传递的原则。把数组长度藏在全局变量里是最糟糕的方案，会让代码完全不可复用。

5. 今天实战操练：三个数组题目复盘

5.1 题目一：数组去重，从暴力到优雅

第一个练习是“数组去重”，看似简单，但搜索热度高说明很多人会在面试或实际项目里遇到。假设输入数组是[3, 1, 2, 1, 3, 4, 2]，希望得到不重复元素数组，顺序可以保持不变或按照排序后的结果。

基础做法是建立一个额外的标记数组，遍历原数组时判断当前元素是否已经出现过。如果输入的元素范围固定且不大，可以用bool数组做哈希标记；如果范围不确定，用哈希集合set或unordered_set会更方便。代码大概是这样：

cpp复制vector<int> removeDuplicates(const vector<int>& nums) {
    unordered_set<int> seen;
    vector<int> result;
    for (int x : nums) {
        if (seen.find(x) == seen.end()) {
            seen.insert(x);
            result.push_back(x);
        }
    }
    return result;
}

如果题目要求原地去重且允许改变顺序，那可以先对数组排序，然后使用相邻元素比较的策略，让所有重复元素都挤在一起再一次性过滤。C++的unique算法就是这么实现的，不过std::unique只是把不重复元素移动到前面，真正删除还是要配合erase操作。这种方法的好处是不消耗额外哈希表，空间复杂度O(1)，代价是排序带来的O(n log n)时间。

5.2 题目二：双指针合并有序数组

第二个练习是从热词“双指针合并有序数组”里选的。这个题目让我理解了指针在数组中到底是怎么起作用的。假设两个升序数组nums1和nums2，要把它们合并到新数组里，我按空结果数组的方式来做：

cpp复制vector<int> mergeSortedArrays(const vector<int>& a, const vector<int>& b) {
    vector<int> result;
    result.reserve(a.size() + b.size());
    size_t i = 0, j = 0;
    while (i < a.size() && j < b.size()) {
        if (a[i] <= b[j]) {
            result.push_back(a[i++]);
        } else {
            result.push_back(b[j++]);
        }
    }
    while (i < a.size()) {
        result.push_back(a[i++]);
    }
    while (j < b.size()) {
        result.push_back(b[j++]);
    }
    return result;
}

我实测跑了几组数据都没有问题，几个关键逻辑也值得复盘。第一，while循环里用小于等于而不是小于，能让两个数组里值相等的元素保持原有先后顺序，这个特性叫稳定性，对后续排序要求高的场景至关重要。第二，第一个循环结束后，必定还有一个或两个数组没有遍历完，要分别写两个收尾循环。这段逻辑虽然简单，我刚开始会漏掉收尾循环，因为在测试数据恰好两个数组等长且最后一个元素被先处理完时不会暴露问题，直到换了一组数据才翻车。

5.3 题目三：数组转字符串，别忽略边界

第三个练习是从“数组转字符串”这个热词来的，这个话题在JavaScript项目中太常见了。思路很清楚，遍历数组，把每个元素转成字符串拼接，元素之间插入分隔符。可踩的坑也很明显：分隔符加的位置不对，开头和结尾会多个分隔符。

用C++实现数组转字符串时，我的建议是先把所有元素写入ostringstream，再逐项判断是否需要加分隔符：

cpp复制string vectorToString(const vector<int>& nums) {
    ostringstream oss;
    for (size_t i = 0; i < nums.size(); i++) {
        if (i > 0) {
            oss << ",";
        }
        oss << nums[i];
    }
    return oss.str();
}

这种“先判断是否第一个，再决定加不加分隔符”的写法，好过于先拼再删末尾字符，因为后面一种方式依赖字符串删除操作，代码上绕了一层。JavaScript里的arr.join(",")就是封装的同样逻辑，用起来最舒服。但是如果数组某个元素是undefined或null，js里join方法处理值和显式插入"undefined"是有差异的，这属于实际项目中很容易被忽略的边界情况。

6. 今天踩过的坑，整理成排错经验

6.1 数组越界没有“编译错误”不等于安全

我第一天练习时更习惯写循环，很少主动检查边界。今天写滑动窗口时把right初始化为0，但窗口收缩条件用的是left < right，在空数组输入情况下，数组访问一下子就到了-1的位置，程序没有崩溃，却返回了错误结果。排查半天才发现是空数组边界问题。

经验是：只要代码处理的数组可能为空，循环开始前就要做空数组判断。数组越界后程序不一定报错，它可能读的是相邻内存中的残留数据，这种“不报错”恰恰是最危险的，因为它会提供一个看似合理的结果，让问题深埋到代码里。

排错时建议用assert或日志把数组下标和当前元素值打出来，尤其在循环需要跳过某些元素时，检查计算出的下标是否始终在0到size-1区间内。这种防御性检查在生产代码里也不丢人，很多时候能直接在发布前拦住问题。

6.2 使用未初始化的数组，垃圾值真的会害人

搜索热度里“数组初始化”出现不止一次，说明很多人踩过这个坑。在C++中，如果你写int arr[10];，在栈上创建数组，它的元素值是不确定的，可能残留内存里原有的垃圾数据。如果后面没有对每个元素赋值就直接用，程序出现的随机性错误非常难查。

我在练习中设计了一个误区实验，故意不初始化数组，直接打印，发现每次运行结果都不同，但这个“不同”在单次运行里根本看不出来。等我把某个判断逻辑写上去，测试数据有时过有时挂，这就是典型的未初始化数组造成的随机行为。解决方案是必须在使用前为数组每个元素赋初值，C++里可以用int arr[10] = {0};，会把它全部初始化为0。如果数组比较大且要填充特定值，则不要自己写长循环，建议使用std::fill或std::fill_n。

6.3 函数形参把数组当指针用，sizeof结果不对

在C++里写函数，参数写成int nums[]和int* nums其实是同一个意思，数组会退化成指针。给元素赋值时可以直接改原数组，因为传的是地址，而一旦在函数内部使用sizeof计算数组长度，得到的结果就会是8，而不是数组真正的字节数。

为了验证是否影响大数组操作，我试了在函数里把数组第一个元素改掉，返回后原数组的值确实变了，因为传入的是地址。可是如果只是想实现“只读遍历”，这些修改就属于“副作用”，会导致意外逻辑错误。更好的写法是使用std::vector，或者在传参时特别标记const int nums[]，再配合explicit长度参数。今天真正认识到了“能用容器就不用裸数组”这句话的价值。

6.4 把列表和数组的概念混着用

刷题时常见到题目描述里一会儿叫“数组”，一会儿叫“列表”。在算法语境下它们大多数是可以互换的，但在不同语言里，逻辑关系完全不同。C++的std::list是链表，和数组内存结构不一样；Python的list实际上更像是动态数组。概念混淆会直接导致选错数据结构，进而在分析复杂度时出错。

我今天的经验是，看到题目先问三个问题：元素存储是否连续？是否支持随机访问？中间插入的代价是高还是低？回答完这三个问题，数据结构就定了一大半。如果回答是连续、随机访问、插入代价高，那基本就是数组或动态数组，凡是频繁中间插入的题目就不能硬用数组去解，及早换成链表能少走很多弯路。

6.5 手动删除元素后，忘记容量已经改变

很多人在写数组遍历删除时，会用一个for循环从头遍历并执行erase操作，这是一个很容易踩的坑。因为erase会让后面的元素整体前移，下标i指向的元素已经发生了变化，继续执行i++会跳过元素。这个坑在热词“JS数组操作元素”里也经常翻车。

写一段这类错误代码的典型特征，就是打印结果发现有一半元素没被删掉。解决办法有两种：一是删除元素后立即对当前下标减一，重新访问这个新移过来的元素；二是采用从后向前遍历删除。推荐尽量用从后往前遍历，或者用双指针筛选出需要保留的元素再去覆盖，思路更清晰，性能往往也更好。

7. 下一次练数组前，我会带上的几个习惯

7.1 先用伪代码定区间规则，再写实现

今天练了二分查找、双指针、滑动窗口后，我最大的感悟是写数组题之前，一定要用伪代码把区间是“闭区间还是开区间”、移动条件是什么、“每次更新是mid加一还是减一”先列出来。只要这些问题没想清楚，代码本身就必然带着模糊性。这些边界细节不是靠背代码就能掌握的，必须每个细节都经过反复验证。

7.2 遇到数组操作先问自己有没有重复遍历

数组优化的核心其实就一条主线：把重复遍历去掉。能用O(n)完成的操作，就不要用O(n²)。双指针和滑动窗口本质上都是通过让指针只往一个方向移动来压缩重复计算。写完一个数组解法后，可以专门花一分钟思考，我的代码里是否存在可以从头再来避免的多余扫描，如果存在，很大概率能换成双指针或者前后双循环。

7.3 长度和下标分离理解，越界概率会小很多

数组下标从0开始，长度是n的数组，最后一个元素的下标是n-1。这个简单事实在写复杂逻辑时容易被忘掉，特别是越界风险高的滑动窗口代码里。我的习惯是尽量用变量名把“下标”和“大小”区分开，比如index代表当前访问位置，size代表数组长度。这样不仅能提升可读性，还能在手动检查代码时快速定位到每一步是在取下标还是取长度。

今天一天结束后，我再回过头去看最开始的那些搜索热词：C++二维数组、指针数组、数组去重、合并有序数组、树状数组二分。能发现这些问题的核心其实都依赖数组的几个基础特质：连续存储、下标计算、O(1)随机访问，以及从这些特质延伸出的各式操作手法。算法学习day2远没到能用“简单”来评价的程度，它更像一个地基，所有上层的高效结构，树、堆、哈希表，有的是数组的扩展，有的是为了解决数组某种操作太慢而出现。我只希望这些笔记里的思考过程和实战经验，能让同样在这些问题上绕圈的同行们少花一些无谓的排查时间。