数组指针与指针数组：优先级、内存布局与常见误用全解析

不知道你有没有被这样的问题逼疯过：同样写下 int *p[3] 和 int (*p)[3]，一字之差，一个是“数组”，一个是“指针”；一个先跟下标结合，一个先跟星号结合。我在前几年带新人时发现，十个里面有八个会把这两个概念背反，哪怕是写过两年代码的人，也时常在函数传参、动态二维数组、字符串列表这些场景里被按在地上摩擦。这篇东西我就把这些年踩过的坑、看过的核心逻辑一起整理出来，不搞那种看三遍还半懂不懂的背诵口诀，而是从类型、内存、编译器的角度把这两个概念彻底撕开。

这篇文章适合刚学完指针基础、对“数组名和指针”开始怀疑人生的读者，也适合工作了一两年看到这两个词依然要先翻资料的开发者。看完你至少能解决三个核心问题：第一，看到复杂的指针声明能靠规则拆明白；第二，遇到二维数组、字符串列表这些场景，知道该用数组指针还是指针数组；第三，面试被问到这两个概念时，能把“为什么”说得清清楚楚，而不是只背出结论。

1. 两个概念，越学越浑？先看声明在“骗”你什么

1.1 优先级才是罪魁祸首

C 语言里有一类知识点，不是难在算法，而是难在语法本身。“数组指针”和“指针数组”这一对就是最典型的例子。背后的根本原因是操作符优先级：[] 下标操作符的优先级高于 * 解引用操作符。就这么一条规则，导致同一个变量名和同一个类型符号组合在一起，能产生完全不同的含义。

先看 int *p[3]。因为 [] 优先级高于 *，所以 p 先和 [3] 结合，说明 p 本身是一个容量为 3 的数组。既然 p 是数组，数组元素是什么呢？元素类型由剩下的 int * 决定，也就是“指向整型的指针”。所以这句话翻译成人话就是：p 是一个数组，里面装了 3 个指向 int 类型的指针。

再看 int (*p)[3]。括号在 C 声明里永远是最强优先级，它强行让 p 先和 * 结合，于是 p 首先是一个指针。指向的目标是什么呢？越过右边的 [3] 可以知道，这个指针指向一个包含 3 个 int 元素的数组。所以这句话翻译成人话就是：p 是一个指针，它指向一个“能装 3 个 int 的数组”。

这两者从内存布局到用处都完全不同，唯一的共同点就是写法长得像，造成的后果就是初学者把这两张脸反复搞混。我在很多代码评审里见过有人写下 int (*p)[3]，心里想的却是“三个指针变量”，然后往里面塞 &a、&b、&c 这种地址，编译之后报了一堆错还不知道为什么。只有先意识到“优先级是罪魁祸首”，你才能在声明这一关把概念掰正过来。

1.2 用一个“右左法则”把声明读明白

遇到那种嵌套了括号、数组、指针的复杂声明，与其凭记忆硬猜，不如掌握一套通用的阅读方法。这个方法在很多经典教材里被称为“右左法则”，我在这里用最简单的方式讲一遍。

从标识符 p 开始向右看，如果遇到右括号 ) 或者 ]，就先改变方向，回头往左看括号内的内容；得出一个结论之后，再跳出这层括号继续向右看，如此反复，直到整个声明读完。以 int (*p)[3] 为例：先从 p 开始向右看，发现右边是 )，那就把注意力转到括号左侧，看到 *，于是得到第一条结论“p 是指针”。接着继续往右看，此时已经跳出内层括号，右侧是 [3]，说明指针指向的对象是一个长度为 3 的数组。最后再看这些数组元素的类型，左端写着 int，于是整条声明宣告破译：p 是指向“具有 3 个 int 的数组”的指针。

这个方法不需要你背表的顺序，只需要记住两条原则：变量名先和最近的符号结合；[] 和 * 同时出现时，谁离变量名近谁先结合。用这个方法拆 int *p[3] 也一样，“p 先遇到 [3]，说明 p 是数组，元素是 int*”。“右左法则”对后面读函数指针、指针数组套指针这类更复杂的声明同样有效，今天这两个概念只是它的入门演练。

1.3 先在心里建立一张对比表

为了能把这两个概念彻底区分开，我整理了一张对比表。这张表我建议你保留下来，每次写代码不确定的时候拿出来看一眼。

很多人会在这里提出一个问题：既然 C 语言里数组名会被“退化”成指针，那 int p[3][4] 和 int **p 是不是就可以混用？这是一个非常经典的错误，后面我会专门展开讲。这里先记住一句话：数组名退化成指针是“语法层面的自动适配合法化”，不代表数组和指针在类型系统里是一个东西。二维数组的退化结果是“数组指针”，不是“指针的指针”，差了整整一个概念层级。

2. 数组指针，真正指向“一个数组整体”的指针

2.1 数组指针背后的步长差异

数组指针最让人迷惑的一点是：它的地址值和某些一级指针的地址值可能打印出来一模一样，但只要做一次指针加法，立刻看出天壤之别。我们可以拿一个二维数组 int a[2][3] 来观察。

如果声明 int (*p)[3] = a，那么 p + 1 跨过的不是一个 int，而是整整 3 个 int，也就是一跳会跳过“一行”。原因就在于 p 的类型是 int(*)[3]，它指向的目标是一个“装 3 个 int 的数组”。指针的加法并不是简单地在数值上加 1，而是“当前位置的地址 + 目标类型的大小”。目标类型是 int[3]，大小按 3 个 int 算；所以在 64 位系统下，(char*)p 多打一遍就会发现地址值差了 12 字节（假设 int 是 4 字节）。

我刚学的时候也总觉得这是绕弯子，为什么要费劲搞一个数组指针，直接拿 int* 挨个访问不行吗？当然行，但如果你要表达的本来就是“整行整体”的语义，你把指针的步长定义成元素大小，代码里就要手工计算偏移量。比如拿 int* q = a[0] 去访问第二行，你得写 q + 1 * 3，一旦行数一多、访问方式一变，这个换算就布满了 bug。数组指针的出现就是为了让编译器帮你管这件事：跳一行就是加一个目标数组的大小，这个语义由类型自带。

2.2 数组指针与二维数组名的关系

教材里常有“二维数组名是数组指针”这种说法。必须明确指出：这句话是“用起来方便”的偷懒表达，正确说法应该是“二维数组名在绝大多数表达式中会隐式退化为数组指针”。

举个例子，int a[2][3] 的类型是 int[2][3]，对它取 sizeof，结果是两个数组各自 3 个 int，总共 6 个 int 的空间大小。但当你把 a 作为右值丢给另一个变量时，它通常会退化成一个 int(*)[3] 类型的指针，这个指针指向第一行数组。正是这种退化机制，使得 int (*p)[3] = a 能通过编译，因为此时左右两边类型匹配上了。

但如果你把数组名当成指针来取大小，就会掉进经典的陷阱。比如在函数里写：

c复制void foo(int arr[2][3]) {
    printf("%zu\n", sizeof(arr)); // 实际得到的可能是指针大小
}

看起来 arr 像二维数组，但因为函数形参只是“长得像数组”，编译器早就把形参调整成指针了，落到运行时，这里 sizeof 的结果往往不是你想要的整块二维数组的大小。要正确处理这种场景，要么把数组真正按引用传进来（C++ 里可用模板），要么老老实实把维度信息也通过参数传进去。后面我还会专门讲这个问题。

2.3 sizeof求不出的痛：函数参数里数组的真相

既然刚才已经提到函数参数，这里就展开细讲，因为这是“数组指针”和“指针数组”最容易让人崩溃的战场。C 语言有个流传了半个世纪的设计规则：如果把一个数组作为函数参数传入，编译器会把它调整成“指向数组第一个元素的指针”。语法上你可以写成 void foo(int a[])，也可以写成 void foo(int *a)，这两者在函数参数列表中完全等价。

对二维数组来说，规则继续生效。看这个原型：

c复制void printMatrix(int m[][3], int rows);

它等价于：

c复制void printMatrix(int (*m)[3], int rows);

第二种写法正是数组指针。很多新手认为第一种写法比第二种更好懂，觉得“我就是在传一个二维数组”，其实在函数内部，m 就是一个数组指针，用它访问 m[r][c] 时，编译器需要知道一行有多大才能跨行计算地址。这个“一行有多大”就写在 [3] 里，因此二维数组作为参数时，第二维及之后的维度必须写清楚，这就是很多初学者漏掉维度导致编译失败的原因。

理解了这一点，你就明白为什么面试题总爱问“数组作为参数会退化”的问题。它考察的不是背结论，而是你是否清楚：一个函数拿到一个只有首地址的指针时，它永远无法仅凭指针本身通晓数组长度、行数、列数等所有维度信息。所以实际工程里，正确做法通常是“数组指针 + 显式维度参数”配合使用。

2.4 C++ 动态二维数组与数组指针的纠缠

C++ 中同样有数组指针的用武之地。比如用 new 创建动态二维数组时，new int[rows][3] 的返回类型本质上就是 int(*)[3]。这意味着你可以这样写：

cpp复制int rows = 5;
int (*dp)[3] = new int[rows][3];
// ... 使用 dp[r][c] 访问 ...
delete[] dp;

这里注意，列数 3 必须是编译期常量，因为 int(*)[3] 这个类型自己携带了列数信息。行数 rows 是可以动态变化的，因为每一跳的行大小是固定的 3 个 int，多少行只影响要申请的总空间大小。

如果是真正完全动态的行列都是运行时决定，很多人会试图使用 int**，再在循环里逐行分配：

cpp复制int **p = new int*[rows];
for (int r = 0; r < rows; ++r)
    p[r] = new int[cols];

这段代码在语法上没问题，行数和列数都能动态指定。但它的行地址并不连续，每一行是独立在堆中分配的。某些高性能场景对这种内存布局很不友好：连续遍历一行没问题，但如果要按列频繁访问，缓存命中率会明显下降。更好的做法是直接用 std::vector<std::vector<int>>，图省事就用它；如果对性能敏感，可以考虑分配一整块连续内存，再写一个下标封装，比如 data[row * cols + col]。不要把指针数组的用法硬搬到动态矩阵里，否则会让自己在内存布局的坑里挣扎。

3. 指针数组：数组里装指针的小仓库

3.1 声明含义与内存排布

指针数组，字面意思已经很直白：它本身是一个数组，数组的元素类型是指针。读法上可以让它和数组指针形成一条反向思考链：数组指针是“用一个指针去操作一个数组”，指针数组则是“用一个数组去存放多个指针”。

看一个简单的初始化：

c复制int a = 10, b = 20, c = 30;
int *p[3] = {&a, &b, &c};

此时 p 在内存中是这样的结构：一块连续的内存区域，里面依次存放了 a、b、c 的地址。sizeof(p) 是 3 个指针的大小，在 64 位系统上通常是 24 字节。p[0] 是一个指针，指向 a；*p[0] 等于 10。如果你看到 p[0] 时第一反应是“一个 int”，那就错了，p[0] 是一个地址，只有再解一层引用才是值。这个“一层引用后得到什么”的心理模型必须牢固建立起来，否则后面一旦开始访问字符串列表，很容易写错。

这里的下标访问与普通数组无异，只不过每个元素是地址，不是 int。你可以遍历 p，可以交换 p 里的两个元素，交换的代价就是交换一个指针，非常小。这个特性让指针数组在处理需要频繁重排顺序的对象时很有优势。

3.2 处理字符串列表，是它最高光的场景

指针数组最典型的应用就是“字符串数组”。C 语言没有 Python 里那种天然的字符串列表，只有字符数组与字符指针。要保存多个字符串，可以有两种方案：

第一种，用二维字符数组，比如 char names[4][16]。这种方式的问题是每行长度固定，内存浪费明显。如果你存 3 个字符串，长度分别是 3、5、100，那么 16 这个上限要么不够，要么一堆位置闲置。另外，如果你要对这些字符串做排序，交换两行时，标准做法是一次次复制整块字符内容，成本很高。

第二种，就是指针数组。写法是：

c复制const char *error_msgs[] = {
    "success",
    "out of memory",
    "file not found",
    "invalid argument"
};

每个元素是一个 const char*，指向一个字符串字面量。这里有几个细节要强调：第一，字符串字面量在只读存储区，所以声明里加 const 最稳妥；有的老编译器允许你直接写 char*，但运行时一旦尝试修改未定义行为立刻上身。第二，不同字符串本身并不连续存放，它们是零散的、分布在全球不同的字符常量区，但指针数组把它们的地址集中到了一个连续区域里。数据内容是分散的，索引结构是连续的，这种“空间分散但管理集中”的模式非常适合长度差异大的字符串集合。

基于这个结构，排序就能变成只交换地址的小操作：

c复制for (int i = 0; i < n - 1; ++i) {
    for (int j = i + 1; j < n; ++j) {
        if (strcmp(error_msgs[i], error_msgs[j]) > 0) {
            const char *tmp = error_msgs[i];
            error_msgs[i] = error_msgs[j];
            error_msgs[j] = tmp;
        }
    }
}

交换一次只搬一个 8 字节的指针，不用搬整段字符串，这种模式在 C 时代是非常经典的优化手段。

3.3 函数指针数组，菜单与跳表的骨架

指针数组的另一个高度重要的变体是“函数指针数组”。所谓函数指针，就是指向函数的指针变量，把它放进数组里，就形成了“一个根据下标直接选择函数”的分发结构。

举个例子，如果要在命令行工具里实现指令路由，可以直接写一串 if-else：

c复制if (strcmp(cmd, "start") == 0) start();
else if (strcmp(cmd, "stop") == 0) stop();

这种代码每加一条新指令，就要改主分发函数，而且 if-else 链条越来越长。更优雅的方式是定义一张静态映射表：

c复制struct Command {
    const char *name;
    void (*handler)(int);
};

static const struct Command commands[] = {
    {"start", start_handler},
    {"stop", stop_handler},
    {"status", status_handler}
};

这里其实并不是严格意义上的函数指针数组，因为每个元素是一个结构体，里面包含了名字和处理函数指针。但如果你不关心名字，希望用下标直接选择逻辑，函数指针数组就登场了：

c复制void (*actions[])(void) = { action_init, action_run, action_cleanup };

执行第 i 步就写 actions[i]()，以数据驱动的方式把“选择分支”扁平化成数组索引。C 语言里像状态机、菜单系统、命令解析器，本质都是这个思路。理解指针数组之后，这些设计就不需要额外记模板了，它们只是“数组元素是指针”在各种领域里的具象化应用。

3.4 指针数组与二级指针，别混为一谈

第二个高频混淆点出现在这里：int *p[3] 是一个数组，数组名 p 退化成首元素地址时，首元素类型是 int*，因此指针类型应当是 int**。于是很多人就把“指针数组”和“二级指针”划等号。这句话在前半段对，在后半段不完全对。

能画等号的是“退化后的值”，不能画等号的是“对象本身的类型”。数组在内存中是紧凑连续的一组指针，而二级指针只是一个保存地址的变量。例如：

c复制int *p[3];
int **pp = p;  // OK：p 退化成 int**，指向第一个 int*

这样写是可以的，pp[0] 就是 p[0]。但如果有人把所有的二维数组都拿来强塞给 int**，就踩了大坑。比如：

c复制int matrix[2][3];
int **pp = matrix; // 错误，类型不匹配

matrix 退化的目标是 int(*)[3]，也就是数组指针，不是 int**。二维数组的底层内存是一长串连续 int，里面根本不存在“一个数组，里面放着三个指向每行的指针”这样的结构。内存差异决定了类型差异，这是不能靠强制转换回避的语义错误。

用一个最简单的例子说明两者差异：matrix[0] 在表达式里是一个长度为 3 的 int 数组，它会再退化成 int*，这个指针指向第一行首个元素；而真正的 int** 解引用一次应该得到一个 int*，这个 int* 背后必须有真实存在的指针变量或指针元素。int matrix[2][3] 的第一行只是 3 个 int，不是 3 个指针，因此强扭的类型在内存解释上完全对不上。

4. 常见错误：问题九成出在“类型概念”上

4.1 编不过的现场：int()[N] 和 int 不是一家人

我在帮别人排查代码时，最常看到的问题基本都写在一个模式里：想把二维数组直接丢进某个函数，函数形参却写成了 int* 或 int**。

来看一个典型错误：

c复制void func(int *arr) {
    // ...
}

int a[3][4];
func(a); // 编译会警告或报错

为什么？因为 a 退化后类型是 int(*)[4]，和形参 int* 不一致。有些编译器只给 warning，但如果代码里开启使用 -Werror，当场就无法通过。正确写法理应是：

c复制void func(int (*arr)[4]) {
    // ...
}

另一个常见问题混淆了取值层次。*(p + 1) 在数组指针里得到的是“一行的首地址”，因为 p 指向整行数组，解引用后得到这一行的数组名，而数组名再退化才变成行首指针。如果你以为解一次就拿到 int，后面写 *(*(&a + 1)) 这类复杂表达式时，会一头雾水。调试方式其实很简单，用 gdb 或者随便写几行打印，把地址和值的层级分开看，问题就会暴露得很清楚。

4.2 释放动态内存：malloc 次数要和 free 次数对上

在二维动态结构里，内存释放顺序也是重灾区。如果使用“真正二维”的指针数组方式：

c复制int **p = malloc(rows * sizeof(int*));
for (int r = 0; r < rows; ++r)
    p[r] = malloc(cols * sizeof(int));

释放的时候必须逐行 free，再释放外层指针：

c复制for (int r = 0; r < rows; ++r)
    free(p[r]);
free(p);

如果你忘了释放内层行，只释放 p，就会造成内存泄漏；如果你反过来先 free(p)，再 free(p[r])，那么 p[r] 已经被释放的指针访问到，产生 use-after-free。

如果使用数组指针一次分配连续内存：

c复制int (*p)[4] = malloc(rows * sizeof(*p));

释放时只需要一次 free(p)，不要尝试逐行 free。每一行不是独立分配的，它们属于同一次 malloc 分配的整块内存，逐行 free 是非法操作，会让堆管理器崩溃或报错。牢记原则：malloc 了多少次，free 就必须相应多少次；如果你只 malloc 一次，那就只能 free 一次。

调试上我特别推荐 AddressSanitizer。只要编译时加上 -fsanitize=address，运行程序时它会明确告诉你哪一行是非法释放、哪个指针越界了，比靠 printf 打屏排查高效太多。

4.3 gdb 与编译选项，把类型问题揪出来

排查这类类型问题时，我最常用的手段有两个。

第一个是打开强警告。GCC 和 Clang 都支持：

bash复制gcc -Wall -Wextra -Wpedantic -Werror test.c

加 -Werror 的核心目的，是把所有编译警告直接升级为错误，不给自己留“这个应该没问题吧”的侥幸空间。很多指针类型不匹配的问题，在默认编译参数下只产生 warning，一旦代码规模大起来，人眼会自动忽略 warning 里的信息，最后运行期崩溃。开启 -Werror 后，这些问题在编译阶段就会暴露。

第二个是 gdb 的 ptype 命令。当你不确定一个变量的类型时，直接在调试器里问编译器要答案：

bash复制(gdb) ptype a
(gdb) ptype p

看到 “type = int (*)[4]” 和 “type = int *[4]”，二者的区别一目了然。再配合 x 命令打印内存内容：

bash复制(gdb) p &a
(gdb) p a
(gdb) x/6dw a

可以同步看到地址值、退化后的值和连续 6 个 int 的十六进制/十进制内容，把所有概念翻译到内存层面。

4.4 分清再动手：一张排查速查表

我把平时见过的高频错误、现象和正确思路整理成了一个速查表，供直接实践参考。

每次写代码前，先问自己三个问题：我这个变量到底是什么？它指向的那块内存是一次性的还是分多次分配的？我要使用下标运算符，编译器能根据已知类型算出偏移吗？这三个问题能挡住绝大多数低级错误。

我个人在实际操作中的体会是，指针数组和数组指针这类题，本质上不是靠“多做几道语法题”能救回来的知识。它更像是先在脑子里建好一座内存地形图，知道每个变量在图上占了多大区域，哪个格子存的是地址，哪个格子存的是数值，再从地图视角去理解类型系统为什么这样设计。一旦你建立了这种层级的地址观，再去写 int (*p)[3] = a; 这类代码，你会清楚地意识到自己正在操控的是一整行还是一整块，是“指针数组”还是“数组指针”，自然不容易翻车。