深入理解数组：从内存模型到双指针、前缀和与滑动窗口

先问一个问题：如果让你用一句话解释数组是什么，你会怎么说？我面试过不少人，也带过刚入门的朋友，听到最多的回答是“数组就是连续内存里存一串相同类型的数据”。这句话没有错，但离真正理解这个数据结构还差得远。实际上，数组不只是教科书里最基础的数据结构，它还是几乎所有高级数据结构的“地基”，也是最常用的数据容器。

今天这篇初阶文章，我就把“数组”这个看起来简单到不需要讲的东西，从头到尾拆开聊一遍。你会看到它为什么查询快、插入慢，下标为什么从 0 开始，C 语言里数组为什么总让人踩坑，Python、JavaScript、Go 里的“数组”又和 C 语言有多大区别。最后我会带你把双指针、前缀和、滑动窗口这几个最经典的数组算法套路过一遍，让“数组”真正成为你后面学任何数据结构都甩不掉的能力底座。

1. 从一次面试回答说起：数组到底“基础”在哪里

1.1 几乎所有数据结构都在复用“数组思维”

很多人学数据结构有一个误区：数组太简单，跳过，直接从链表开始。但如果你愿意往底层看一眼，会发现栈、队列、哈希表、堆、并查集、树状数组、线段树，这些东西的工程实现里，几乎都有数组的影子。

举个例子。哈希表的底层本质是一个“桶数组”，每个桶里再挂链表或者继续用开放寻址法；二叉堆为了能用 shiftUp 和 shiftDown 调整位置，直接把完全二叉树按层序遍历压进一个数组，所以 2i 和 2i+1 就是父节点和子节点的下标关系；图的邻接表在很多教科书里甚至用数组来模拟链表，每个节点存 next 下标，而不是真的去 new 一个链表节点。

这就是我常说的“数组思维”：用一块连续空间，通过下标计算直接定位数据。链表、树、图这些结构解决的是“如何在非连续空间里组织关系”，但它们的各种优化版本，最后往往又绕回数组。你越往后学越会发现，谁能把下标玩明白，谁就能把线段树、树状数组、KMP 的 next 数组这类东西理解得越透彻。

1.2 先看看初阶阶段会遇到哪些高频问题

如果把范围缩小到初学和求职阶段，和数组直接相关的高频考点其实非常集中：数组去重、数组扩容、字符串数组初始化、指针数组、多维数组与指针的关系、KMP 中的 next 数组、树状数组上的二分、数组作为函数参数时为什么 sizeof 失效……

这些问题看起来五花八门，但把所有问题放一起看，你会发现它们全都可以归结到数组的四个基本性质上：

• 地址连续，所以按下标访问是 O(1)
• 定长或者动态扩容时有容量概念
• 元素在内存里紧密排列，所以局部性好
• 数组名在表达式里经常退化成指针

后面所有章节其实都在围绕这几条展开。把这几条刻进脑子里，再去刷题或应付考试，你会发现自己不是在背结论，而是在用底层原理推结论。

2. 内存模型与下标机制：数组为什么快，快在哪里

2.1 下标的本质不是“第几个”，而是“偏移量”

先做一道简单的 C 语言地址实验：

c复制#include <stdio.h>

int main(void) {
    int a[5] = {10, 20, 30, 40, 50};
    for (int i = 0; i < 5; i++) {
        printf("&a[%d] = %p\n", i, (void*)&a[i]);
    }
    return 0;
}

按 64 位系统、int 占 4 字节的情况，打印出来的地址通常是这样的关系：

code复制&a[0] = 0x7ffc12345000
&a[1] = 0x7ffc12345004
&a[2] = 0x7ffc12345008
&a[3] = 0x7ffc1234500c
&a[4] = 0x7ffc12345010

每个地址差 4 字节，正好是一个 int 的大小。从这个实验里能推出数组最核心的计算公式：

code复制address(a[i]) = base_address + i * sizeof(element)

所以下标 i 的本质不是“第几个元素”，而是“相对于起始位置的偏移量”。正因为偏移量从 0 开始计算最自然，数组下标才从 0 开始。如果从 1 开始，公式就得变成：

code复制address(a[i]) = base_address + (i - 1) * sizeof(element)

多一次减法，虽然现代编译器能优化掉，但从语言设计角度，0 才是硬件层面最直接的表达。这也解释了为什么面试官爱问“为什么数组下标从 0 开始而不是从 1 开始”这种问题——他想确认你到底是背了答案，还是真的懂地址计算。顺带一说，Lua 和 MATLAB 这种从 1 开始的语言，纯粹是为了人类阅读方便，底层实现照样是偏移量那一套。

2.2 连续内存带来的两个隐形成本优势：随机访问与缓存命中

数组按下标访问能做到 O(1)，靠的就是上面那条地址公式：给定下标，CPU 直接做一次乘法加一次加法，就能算出内存地址，然后取数据。链表的第 k 个节点呢？你得从头节点开始，一个一个 next 走下去，复杂度是 O(n)。

这个差异大家都懂，但还有一层容易被忽略的优势：缓存命中率。

CPU 读内存不是一次只读一个字节，而是按“缓存行”为单位加载，常见的缓存行大小是 64 字节。数组里的元素一个挨一个，遍历数组时，前几个元素被加载后，后面一大片数据大概率已经在缓存里了。而链表节点散布在内存各处，每跳一个节点都可能触发一次缓存未命中，速度自然慢不少。

我自己的实测经验是：在数据量达到几十万、操作又是纯遍历时，数组实现往往比链表实现快一个数量级。你从复杂度上看两者明明都是 O(n)，但常数项完全不同。这就是为什么很多系统底层优先选数组而不是链表做容器，工程上的“快”，往往是缓存友好带来的。

3. 数组的增删改查能力边界：为什么查找快、插入慢

3.1 数组最舒服的操作：按位置读写

数组最爽的操作就是按下标随机读写。想改第 3 个元素，直接 a[3] = 100 就完事，时间开销恒定，和数组长度无关。这也是数组被称为“随机访问”结构的原因。

但如果要按值查找，就没这么舒服了。无序数组里找一个数，你得从头扫到尾，平均要比较 n/2 次，复杂度 O(n)。只有数组有序时才能用二分查找，把查找降到 O(log n)。这正是排序算法在数组问题上地位极高的原因之一：先付出 O(n log n) 的排序成本，后面可以享受无数次 O(log n) 的查找。

这里有个小细节值得记住：二分查找依赖的是“下标可计算”这个数组核心性质。因为数组支持 O(1) 随机访问，才能直接定位中间位置。如果把这段逻辑放在链表上，即使链表有序，每次取中间节点都要从头走一遍，二分就没意义了。你会在很多面试题里看到“有序链表查找为什么不能用二分”的讨论，答案的根子就在这里。

3.2 插入和删除为什么这么贵

数组的弱点在插入和删除。

往数组中间插入一个新元素，你得把插入位置后面的所有元素整体向后挪一位，才能腾出空位。删除元素时反过来，后面的元素要整体向前补位。这两种操作的时间都和数据规模成正比，最坏情况是 O(n)。

如果只考虑中间位置插入，假设每个位置被选中的概率相同，那么移动次数的平均值就是：

code复制(1 + 2 + ... + n) / n ≈ n / 2

删除操作平均也要移动 (n-1)/2 个元素。数据量一大，这种操作会非常痛苦。用生活里的例子类比，数组就像一排摆得满满当当的书架。你想在两本书中间插一本，必须把后面所有书先拿下来，往右推，再把它们放回去；想抽掉中间一本，要再把后面的书向左移。链表则像一长串锁在一起的积木，拆装某一节只需要调整前后两个节点的连接，代价是找某一节时得从头摸过去。

一个简单总结表如下：

3.3 复杂度还得看最好、最坏、平均

初学者经常被“插入 O(n)”和“尾部插入 O(1)”这种表述搞混，其实区分开来很简单：

• 尾部插入的代价和数组长度无关，是 O(1)
• 头部插入要把所有元素都往后移一格，是 O(n)
• 中间插入平均移一半，也是 O(n)

所以“数组插入 O(n)”说的是一般情况，“尾部插入 O(1)”是特殊位置。真正的工程里很少写死“插入恒为 O(n)”这种结论，而是看你的操作分布。如果你总是只在尾部追加数据，那用数组的体验远好于链表；如果你频繁在头部插入，那数组就是灾难。

这一节也为后面讲动态数组扩容埋个伏笔。动态数组在扩容那一刻的插入确实是 O(n) 的，但因为扩容次数很少，把代价平摊到每次追加上，又能变成 O(1)。这个“均摊复杂度”的概念，在高阶数据结构和系统设计里到处都是，建议你现在就从数组开始建立直觉。

4. 初阶最容易踩的坑：越界、传参和指针退化

4.1 越界不报错，但程序会“变脸”

C 语言的数组不检查边界。你写 int a[3]，如果循环里写成 for (int i = 0; i <= 3; i++)，最后一次访问的 a[3] 其实已经越界了，但编译器不会报错，程序运行起来也不会立刻崩溃。问题是，那个地址上存的可能是别的变量、函数返回地址，甚至是相邻数组的元素。你对它写入，相当于在背后偷偷改别人的数据。

我调试过的一个典型案例是：一个 int 数组越界写，把栈上紧挨着的循环变量给覆盖成了 0，而那个循环变量正好是循环的终止条件，结果程序陷入死循环。当时排查了很久，最后用调试器看内存才发现是越界写坑了自己。

这类问题的可怕之处在于，它不会稳定复现。不同编译器、不同优化等级、不同操作系统下，栈布局都可能不同，同样的越界代码这次不报错，下次可能就把程序搞崩。所以防御手段要前置：

• 循环边界一律用 i < n，不要写 i <= n
• 需要越界检测时，用 C++ 的 std::array::at 或 std::vector::at，它们会在越界时抛异常
• 调试阶段用 GCC 或 Clang 编译时加上 -fsanitize=address，越界一发生就立刻报告

AddressSanitizer 是我强烈推荐初学者尽早用起来的工具，它能在开发阶段帮你抓出大量“看起来正常但实际已经越界”的问题，比事后排查省太多时间。

4.2 字符数组的 '\0' 陷阱

C 语言里字符串不是一种独立的容器，它本质就是字符数组，只不过约定以 '\0' 结尾。这个约定带来一堆经典坑。

最直观的例子：

c复制char str[5] = "hello";

看着好像没问题，实际编译器会报警告，因为 "hello" 里实际上有 6 个字符：'h' 'e' 'l' 'l' 'o' '\0'。一个大小为 5 的数组根本放不下。你硬要写进去，'\0' 就越界了。正确的写法要么是：

c复制char str[] = "hello";
char str[6] = "hello";

第二个坑是 strcpy 和 strlen 的行为。strlen 是顺着数组一直数到 '\0' 为止，根本没地方知道数组真实大小。如果某个字符数组忘记加终止符，strlen 会一路读过去，直到内存里某个地方恰好撞上一个 0 字节，得出的长度完全不可控。这也是很多缓冲区溢出漏洞的根源，程序以为读的是字符串，实际上读的是越界内存。

我的建议是，初学阶段尽量用 C++ 的 std::string 处理字符串，不要手动维护 '\0'；如果必须用 C 风格字符数组，养成“每次分配多留一个字节”的习惯，并且在用 strcpy 前先确认目标缓冲区真的够大。

4.3 数组传参后，sizeof 不再是数组大小

这是面试和考试中出现频率极高的考点。先看代码：

c复制#include <stdio.h>

void print_size(int arr[]) {
    printf("inside function: %zu\n", sizeof(arr));
}

int main(void) {
    int a[10];
    printf("in main: %zu\n", sizeof(a));
    print_size(a);
    return 0;
}

在 main 里，sizeof(a) 返回的是整个数组的字节数，也就是 10 个 int 的大小，通常是 40。但进入函数后，sizeof(arr) 返回的是 8——64 位系统下一个指针的大小。

原因在于，数组作为函数参数时，会被“退化”成指针。void print_size(int arr[]) 和 void print_size(int *arr) 在 C 语言里完全等价。函数拿到的只是数组首元素的地址，它知道不了数组长度。

所以 C 语言里几乎所有的数组处理函数都得额外传一个长度参数：

c复制void print_array(int arr[], int n) {
    for (int i = 0; i < n; i++) {
        printf("%d ", arr[i]);
    }
    printf("\n");
}

如果你用 C++，更推荐用 std::vector 或者 std::array，它们自带 size，不会再出现这种信息丢失的问题。

4.4 二维数组与指针：值相同，类型不同

很多人学到这里会懵：int a[3][4] 里的 a、a[0]、&a[0][0]，打印出来地址值都一样，为什么不能互相随便赋值？

因为它们的类型不同，而类型决定了指针加减的步长。

先说存储。二维数组也是连续内存，a[3][4] 一共 12 个 int，按行优先排列。第 i 行第 j 列元素的地址是：

code复制address(a[i][j]) = base + (i * 4 + j) * sizeof(int)

然后看这三个表达式：

• a 的类型是 int (*)[4]，也就是指向“长度为 4 的 int 数组”的指针，a + 1 会跳过一整行，也就是 4 个 int，16 字节
• a[0] 是数组名，在表达式里退化成 int*，指向第 0 行第 0 列，a[0] + 1 只跳过一个 int，4 字节
• &a[0][0] 的类型是 int*，和 a[0] 的地址值相同，步长也相同

这里还有一个更常见的考题：int *p[3] 和 int (*p)[3] 的区别。前者是“指针数组”，数组里放的是 3 个 int*；后者是“数组指针”，一个指向长度为 3 的 int 数组的指针。很多人写二维数组传参时写 void f(int **arr)，其实是不对的，二维数组名退化后是 int (*)[N]，不是 int**。只有在手动维护一个“指针数组”时，才可能出现 int**。

5. 不同语言里的数组并不一样：动态扩容背后的均摊成本

5.1 C/C++：定长数组与动态数组的取舍

C 原生数组是纯粹的定长连续内存，创建时大小固定，之后无法改变。这种设计的好处是零额外开销，坏处是一旦数据量预估不准，要么浪费，要么不够。

C++ 提供了两层补充：

• std::array：定长数组的封装，大小依然编译期确定，但提供了 .size()、越界检查等能力
• std::vector：动态数组，能在运行时自动扩容

std::vector 的思路很值得展开说：它内部维护三个关键信息，指向堆内存的指针、当前元素个数 size、当前容量 capacity。容量可以比 size 大，多出来的空间就是预留的，方便以后追加数据不立刻重新分配。

当你往 vector 里 push_back 时，如果 size 已经等于 capacity，就会触发扩容：申请一块更大的内存，把旧元素全部拷贝过去，释放旧内存。这个操作确实是 O(n) 的，但因为扩容频率很低，整体分摊下来，每次 push_back 的均摊复杂度仍然是 O(1)。

5.2 Python list 看着像数组，其实是对象指针数组

Python 的 list 用起来很像数组，但底层设计完全不同。它的内部是一个 PyObject* 数组，每个元素是一个指向真实对象的指针，而不是对象本体。这带来两个结果：

第一，list 可以装任意类型，因为每个槽位都只是 8 字节的指针，指向谁并不限制。

第二，直接存数字时，实际上是一层跳转：list 先取出指针，再沿指针去拿对象。比起 C/C++ 连续存放 int 的数组，缓存友好性要差一些，这也是 Python 循环里大量操作 list 元素时性能不如原生数组的原因。

list 的扩容策略和 vector 类似，但倍率不同。以 CPython 为例，它通常按大约 1.125 倍的大小扩展，小列表还会额外加一点余量，不同版本会有差异。如果你提前知道要往 list 里灌很多元素，可以用 [None] * n 预先分配长度，省去扩容搬移的开销。

5.3 JavaScript 数组：一个被包装成“数组”的对象

JavaScript 的数组其实更像一个特殊对象，数字下标本质上是对象的键。这也是为什么你能写出 arr[1000000] = 1 且中间元素全是空位。

现代 V8 引擎为了让数组跑得快，会尽量把它优化成真正的连续内存。一个普通的 [1, 2, 3] 在 V8 内部可能是 PACKED_SMI_ELEMENTS，整数数组；一旦你 push 一个浮点数进去，它会升级成 PACKED_DOUBLE_ELEMENTS；再 push 一个字符串，升级成 PACKED_ELEMENTS。每次升级都会带来一定性能损耗，而且基本不可逆。这解释了为什么有时候往数组里混入不同类型数据后，性能会明显下降。

还有一个常见坑：delete arr[1] 这种操作会在数组中间挖出一个空洞，V8 无法继续用密集数组表示它，可能退化成字典模式，各类数组方法的性能都会受影响。如果你确实需要删除元素，用 splice 而不是 delete，虽然 splice 要搬移元素，但至少结构不会退化。

5.4 Go 切片与动态扩容背后的均摊成本

Go 语言里有一个更清晰的层次：数组是值类型，定长；切片是数组的一层包装，类似 vector。

切片内部是三元组：

go复制type slice struct {
    ptr  unsafe.Pointer
    len  int
    cap  int
}

append 时如果容量不足，切片会申请一块更大的连续内存，把旧元素复制过去。Go 的扩容策略在不同版本里有所调整，早期小切片通常是翻倍增长，大切片增长倍数会降低到约 1.25 倍，避免一次性占用太多内存。无论具体倍率怎么变，本质都是一样的：扩容次数按指数减少，总搬移代价摊到每次 append 上，均摊 O(1)。

这个“均摊 O(1)”可以用一个简单计算理解。假设容量从 1 开始翻倍：1、2、4、8、16……要凑够 n 个元素，扩容次数约 log n，每次扩容拷贝的元素总数大约是：

code复制1 + 2 + 4 + ... + n ≈ 2n

所以往动态数组里追加 n 个元素的整体成本是 O(n)，摊到每一次就是 O(1)。这就是为什么现代语言里动态数组完全能撑起绝大多数“数组”使用场景。

6. 从数组走向算法：双指针、前缀和与滑动窗口

6.1 双指针：数组问题最快上手的套路

数组题目里最高频的套路就是双指针，我不止一次说过，把双指针练熟了，很多题就算没见过也能现场推出来。

最经典的场景是在有序数组里找两数之和：

python复制def two_sum_sorted(nums, target):
    left, right = 0, len(nums) - 1
    while left < right:
        cur = nums[left] + nums[right]
        if cur == target:
            return (left, right)
        elif cur < target:
            left += 1
        else:
            right -= 1
    return None

为什么可以这样做？因为数组有序。当前和太小，说明左指针那边的数不够大，只能往右移；当前和太大，说明右指针那边的数太大，只能往左移。每一轮至少排除一个位置，整体 O(n)。

另一个常见场景是原地去重，用快慢指针，快指针负责扫描，慢指针负责记录不重复元素应该放的位置：

python复制def remove_duplicates(nums):
    if not nums:
        return 0
    slow = 0
    for fast in range(1, len(nums)):
        if nums[fast] != nums[slow]:
            slow += 1
            nums[slow] = nums[fast]
    return slow + 1

这种题目初看觉得技巧性强，但核心就是一句话：利用数组下标可计算，用两个下标同时维护“已处理区间”和“待处理区间”。

6.2 前缀和：把区间求和从 O(n) 降到 O(1)

如果数组本身不变，但你要反复计算不同区间的和，每次都遍历一遍显然太浪费。前缀和可以提前把从开头到每个位置的累计和算好，之后任意区间用一次减法直接得到。

python复制nums   = [2, 1, 3, 6, 4]
prefix = [0] * (len(nums) + 1)

for i, x in enumerate(nums):
    prefix[i + 1] = prefix[i] + x

def range_sum(l, r):
    return prefix[r + 1] - prefix[l]

这里的 prefix[i + 1] 表示前 i+1 个元素的和，也就是 nums[0..i]。区间 [l, r] 的和就等于 prefix[r+1] - prefix[l]。为什么要多出一位 0？因为要处理 l=0 的情况，避免越界。很多教材里的前缀和下标设计不一样，但本质都是“用下标差表示区间和”。

这个套路在二维扩展就是二维前缀和，在带修改的问题是树状数组和线段树，但最底层的直觉仍然是：把重复计算提前缓存，用下标运算换取时间。

6.3 滑动窗口：解决连续子数组问题的模板操作

滑动窗口适合处理“连续子数组”相关问题，典型的比如“和大于等于 target 的最短子数组”。

python复制def min_subarray_len(nums, target):
    left = 0
    cur = 0
    ans = float('inf')

    for right, x in enumerate(nums):
        cur += x
        while cur >= target:
            ans = min(ans, right - left + 1)
            cur -= nums[left]
            left += 1

    return 0 if ans == float('inf') else ans

这个代码里，right 负责把新元素纳入窗口，left 负责在窗口满足条件时压缩窗口。因为 left 和 right 都只往一个方向移动，每个元素最多被加入一次、移除一次，所以整体复杂度是 O(n)。滑动窗口能高效的根本原因也依赖数组的连续性和下标计算：窗口左右边界就是两个下标，窗口长度直接相减得到。

如果处理的是链表，窗口移动就没这么自然了，因为链表没有随机访问能力。这个对比会让你更清楚，数组题目的很多高效算法，都是建立在连续下标这个物理本质上。

6.4 排序、二分与计数：数组上的三件套

除了双指针、前缀和、滑动窗口，数组题里还有三个基础操作，几乎每个刷题的人都会反复用到。

排序可以把无序数组变成有序，然后很多问题就都好办了。数组中位数、去重、找最值、按区间合并，排序之后都能用线性扫描解决。判重的场景则可以通过排序或者哈希表。我个人的习惯是：如果要求空间 O(1)，就排序后相邻比较；如果不限制空间，直接上集合。

二分查找依赖有序数组，核心是不断比较中间位置的值，把搜索区间折半。它的难点不在思路，而在边界条件，left < right 还是 left <= right，mid 取左中位还是右中位，都能写出一堆变体。我的建议是固定一套自己熟悉的写法，反复用，不要每次重推。

计数数组适合数值范围有限的场景。比如题目说元素范围在 0 到 100 之间，那就可以开一个长度 101 的 bool 数组标记出现过哪些数，这比哈希表更快。数据范围小到能开数组，就不要犹豫，直接走计数，常数因子小很多。

这三个操作单独看都不复杂，但它们组合起来能覆盖大量所谓的数组难题：先排序再二分，先计数再判断，先双指针再滑动窗口。算法的学习路径从来不是从高深结构开始的，而是把这些基础操作练到肌肉记忆，再面对复杂问题时自然组合。

我自己带新人时，会先让他们把数组相关的经典题做一遍，反复练习下标计算和边界处理，再学链表、树、图这些更抽象的结构。原因很简单，越高级的数据结构，越依赖你对连续空间和下标关系的掌控感。数组这个基础有没有打牢，直接决定后面学哈希表、堆、树状数组、KMP 这些内容时是越学越轻松还是越学越吃力。等你回头再看开头的那些高频问题，会发现它们全都在围绕同一个核心：一块连续空间，一组下标规则，以及你能在这块空间上玩出多少高效操作。