写C语言教程这么多年，我越来越确定一件事：数组是很多人从“看懂代码”走向“写出靠谱代码”的分水岭。学C语言，数组绕不过去，它不像变量那样直白，也不像指针那样一开始就吓人，但恰恰是这种“看着简单”的错觉，让无数人在越界、字符串、函数传参上栽跟头。这篇博文把我实际操作中积累的数组用法、内存理解和踩坑经验整理出来，适合正在学C语言基础、准备计算机二级考试，或者开发嵌入式、单片机程序却被数组搞得头大的朋友。内容我尽量讲得透一点，每一步都告诉你为什么，不光是给结论。
1. 把数组拉直看：连续内存与下标偏移的真相
1.1 数组名到底代表什么
先聊一个基础问题：数组名是什么？很多教材说“数组名是首地址”，这话不算错，但容易误导。
int a[5] = {1, 2, 3, 4, 5}; printf("%p\n", a); // 输出 a[0] 的地址 printf("%p\n", &a[0]); // 输出完全一样 printf("%p\n", &a); // 数值也一样，但类型不同三个打印结果从数值上看完全一致，但a、&a[0]、&a这三者在C语言里的类型是不同的。a和&a[0]类型都是int，指向第一个元素；&a的类型是int ()[5]，指向整个数组。这区别在sizeof和指针运算里会体现出来：
printf("%zu\n", sizeof(a)); // 20，整个数组占20字节 printf("%zu\n", sizeof(&a[0])); // 8（64位系统上指针大小） printf("%zu\n", sizeof(&a)); // 8，指针大小 printf("%p\n", a + 1); // 地址加4，跳到a[1] printf("%p\n", &a + 1); // 地址加20，直接跳过整个数组我自己工作中调试二维数组和高维数据时，经常靠这种“地址差”来确认数据的排列方式。建议你把这段代码敲到编辑器里跑一遍，眼见为实，比背十遍概念都管用。
1.2 下标运算的本质
数组下标访问的本质是地址偏移。C语言里a[i]等价于*(a + i)，编译器会把你写的下标转换成偏移量，再解引用。这就是为什么数组下标从0开始：如果从1开始，访问a[0]就得额外做一次“减一”运算，对早期追求极致的C语言来说，从0开始最省事、最自然。
这里有个很有趣的推论：既然a[i]等价于*(a + i)，那它也就等价于*(i + a)，也就是i[a]。下面这个写法在语法上完全合法：
int a[5] = {10, 20, 30, 40, 50}; printf("%d\n", 2[a]); // 输出30，等于a[2]不过我不建议你在正经项目里写这种代码，别人维护起来会想打人。知道它合法的意义在于：你能彻底理解下标操作本质上就是指针运算的语法糖，这对接下来的二维数组和函数传参会有很大帮助。
再说一个让新手困惑的点：a[i]的地址到底怎么算。编译器拿到a[i]，实际上会计算“数组首地址 + i * sizeof(元素类型)”，然后从这个地址读取数据。所以访问a[3]时，如果数组越界了，编译器不会去检查，它只是老实算出地址、去内存里取值。后果完全取决于那块地址上是什么东西，可能是其他变量，可能是函数返回地址，碰一下轻则数据错乱，重则直接段错误。这一点我后面专门展开讲。
2. 一维数组的声明、初始化与越界陷阱
2.1 静态初始化与缺省值
数组初始化的方式很灵活，但效果差异很大。最容易踩的坑是“只初始化一半时，剩下的元素是什么”。
int arr1[5] = {1, 2, 3}; // 剩下的arr1[3]、arr1[4]自动补0 int arr2[5] = {0}; // 全部为0，最常见的清零写法 int arr3[5]; // 局部数组，元素值不确定 static int arr4[5]; // 静态数组，元素自动为0对于全局变量、static修饰的局部数组，编译器会自动清零；但对于普通局部数组，如果你不初始化，里面的值就是栈上残留的随机数据。很多新手在这个地方翻车：声明了int arr[5]就直接用arr[0]，得到个莫名其妙的巨大数字，然后怀疑编译器有问题。实际上C语言标准从没承诺过局部数组会清零。
一个非常实用的初始化技巧是用“指定初始化器”，C99引入的：
int arr[10] = {[0] = 5, [3] = 8, [9] = 10};没指定的元素自动为0。这个写法在给稀疏表初始化时特别方便，代码也直观。我偶尔会在配置表、查找表里这么用，不需要写一堆循环去赋值。不过要注意，这种写法依赖编译器对C99标准的支持，工程上如果要求兼容很老的编译器，慎用。
关于初始化，还有一个很经典的迷惑：int arr[] = {1,2,3,4,5}; 这种方式不用写元素个数，编译器自动根据初始化列表推导出数组长度。计算方式是sizeof(arr) / sizeof(arr[0])。
int arr[] = {1, 2, 3, 4, 5}; size_t n = sizeof(arr) / sizeof(arr[0]); // 5这个“计算元素个数”的宏在工程里很常用，我想强调的是：它必须在数组定义所在的同一作用域里用，一旦数组作为参数传给函数，sizeof(arr)的结果就变了。具体原因，放到后面“函数传数组为什么丢尺寸”那一节说。
2.2 越界读写的真实后果
C语言数组不检查越界，这既是高效的原因，也是大量bug的来源。声明int a[5]，你去读写a[5]、a[6]、a[-1]，编译器大多不会报错，顶多发个警告，程序运行时的表现也是千奇百怪。
我举几个常见后果：
- 读越界：读到的可能是相邻变量的值，逻辑上产生很难追查的错误；
- 写越界：更危险，可能覆盖别的变量。如果你定义了int flag = 1，然后不小心写了a[5] = 0，恰好a[5]的地址就是flag的地址，程序流程就直接被改了；
- 数组越界覆盖函数栈上的返回地址时，函数一旦返回，程序就跳到一个未知地址去执行，直接崩溃，这也是很多黑客攻击手段的原理。
排查越界问题的“土办法”我很推荐：在数组前后各加一个“哨兵值”。
int guard_before = 0x5A5A5A5A; int arr[10]; int guard_after = 0xA5A5A5A5; // 大量操作 arr 后 printf("before: %X, after: %X\n", guard_before, guard_after);如果前后哨兵值变了，说明代码里一定发生了越界，且越界方向是一目了然的。这个方法在调试单片机程序、没有高级调试工具的环境下特别管用，比纯肉眼看代码快得多。
更正式的手段是用AddressSanitizer编译，GCC和Clang都支持：
gcc -fsanitize=address -g -o test test.c ./test如果程序有越界访问，运行时会直接告诉你第几行越界了。这个工具我在排查野指针、数组越界问题时帮过大忙，强烈建议你从学习阶段就养成“怀疑越界就编上ASan跑一遍”的习惯。
3. 二维数组：数组的数组，别把行指针搞混
3.1 二维数组的内存排布方式
二维数组int a[3][4]在概念上是一个3行4列的表格，但在内存里它仍然是连续的一维排列，按“行优先”顺序存储：先存完第0行的4个元素，再存第1行，依此类推，一共12个int连在一起。
理解了这个排布，很多让人迷惑的等价关系就清楚了：
int a[3][4] = {0}; a[0] // 第0行的首地址，类型 int * a[1] // 第1行的首地址，实际是 a[0] + 4*sizeof(int) a // 二维数组名，类型 int (*)[4] &a[0] // 指向第0行的指针，类型 int (*)[4] * (a+1) // 等价于 a[1]这里最容易混淆的是：a[0]和&a[0]数值相同，但a[0]是int，加1只跳过一个int；&a[0]是int ()[4]，加1跳过整整一行4个int。我用一个计算二维数组元素地址的公式帮你巩固一下：a[i][j]的地址 = 数组首地址 + (i * 列数 + j) * sizeof(元素类型)。就因为这个公式，二维数组的“列数”在指针类型里必须体现出来，否则编译器不知道跳一行要跳多远。
3.2 用指针遍历二维数组的三种姿势
把二维数组传给函数或用指针遍历时，可以有好几种写法，很多人不知道该怎么选。我从实际代码里归纳了三种：
第一种，最直观的下标遍历：
void print_array(int rows, int cols, int a[rows][cols]) { for (int i = 0; i < rows; i++) { for (int j = 0; j < cols; j++) { printf("%d ", a[i][j]); } printf("\n"); } }C99支持这种可变长数组做形参的写法，声明时直接给出两个维度，函数内部可以用rows和cols做边界判断。对于绝大多数应用场景，这个写法可读性最高，推荐优先使用。
第二种，行指针形式：
void print_array(int (*a)[4], int rows) { for (int i = 0; i < rows; i++) { for (int j = 0; j < 4; j++) { printf("%d ", a[i][j]); } } }注意int (*a)[4]的括号不能丢，写成int *a[4]就变成“指针数组”了，两者含义完全不同。我在面试别人时经常用这个考区别：一个是指向含4个int元素的数组的指针，一个是含有4个int指针的数组。工程上如果列数固定，这种写法很常见，因为编译器能确定每行的跨步。
第三种，把二维“拉平”成一维指针：
void print_array(int *a, int rows, int cols) { for (int i = 0; i < rows; i++) { for (int j = 0; j < cols; j++) { printf("%d ", *(a + i * cols + j)); } } } // 调用：print_array(&a[0][0], 3, 4);这种写法本质上是利用了二维数组在内存中连续存储的特性。好处是函数不用知道列数（用行指针时必须知道），坏处是牺牲了一点可读性。我处理从文件里读进来的大量矩阵数据时经常用这种，配合一个专门算偏移的宏，性能好，代码也简洁。
4. 字符数组与字符串：长得像，脾气不同
4.1 字符数组和字符串字面量的差异
字符数组是数组里最特殊的一类，因为C语言没有单独的“字符串类型”，字符串靠字符数组加结尾的‘\0’来模拟。正因为这个设计，很多新手一开始会把下面两种写法混为一谈：
char s1[] = "hello"; char *s2 = "hello";第一行定义了一个字符数组，大小由编译器根据“hello”加结尾的‘\0’自动推断，共6个字节，s1里面的字符可以修改。第二行定义了一个指针，指向只读字符串字面量在内存中的位置，s2[i]这种写操作在大多数平台上是非法操作，可能直接崩溃，或者因为编译器的存储安排产生各种诡异结果。
用strlen和sizeof对比这两者，能立刻看出区别：
char s1[] = "hello"; char *s2 = "hello"; printf("%zu %zu\n", sizeof(s1), strlen(s1)); // 6 5，sizeof包含'\0' printf("%zu %zu\n", sizeof(s2), strlen(s2)); // 8 5，sizeof是指针大小最直观的记忆方法：sizeof是编译器在编译时算出来的，它能知道s1这个数组类型占6字节；strlen是运行时函数，它要逐个字符数，直到碰到‘\0’才停。C语言里的“数组转字符串”这个话题之所以经常有人问，其实就是没想清楚：字符数组本身就已经带着‘\0’才叫字符串，没有结尾‘\0’的字符数组只是一个普通数组，你用%s打印会一直读到内存里随机位置的某个0为止。
4.2 字符串处理函数的边界与原位转换
因为字符串处理完全依赖‘\0’来定界，所以所有操作字符串的函数都有个前提：你确保它在有效范围内能碰到‘\0’。strcpy、strcat、sprintf都是这样。
举个典型翻车例子：
char buf[5]; strcpy(buf, "hello world"); // 危险！源字符串比目标数组长strcpy不会检查目标数组够不够大，直接把12个字符连同‘\0’拷贝过去，覆盖buf后面的内存。工程上更安全的做法是用strncpy或snprintf并指定最大长度：
char buf[5]; snprintf(buf, sizeof(buf), "%s", "hello world"); // 保留3个字符+'#'略不过strncpy有个冷知识：它最多拷贝n个字节，如果源字符串比n短，它会用‘\0’把剩余字节填满；如果源字符串比n长，它不会自动补‘\0’。所以用strncpy之后最好手动保证buf[sizeof(buf)-1] = '\0'。
在需要“字符串逆序”这种操作时，常见做法是原地倒置字符数组。我用的核心逻辑是双指针首位交换：
void reverse(char *s) { if (!s) return; int len = strlen(s); for (int i = 0, j = len - 1; i < j; i++, j--) { char tmp = s[i]; s[i] = s[j]; s[j] = tmp; } }这个函数有个前提：s必须是可修改的字符数组。如果你把字符串字面量传进去，LeetCode或在线判题系统里可能没事，但放到某些嵌入式编译器上就可能段错误。所以调用前先想清楚，你手里的字符串到底能不能写。
5. 数组与指针的退化：为什么函数里收到“尺寸”总是丢
5.1 形参接收数组时的退化规则
我见过太多初学者写出这样的代码：
void print_len(int arr[10]) { printf("%zu\n", sizeof(arr)); // 期望40，实际得到的却是8 }原因在于：函数形参里的int arr[10]会被编译器当作int *arr处理，数组类型“退化”成了指针。C语言为什么这么设计？因为函数调用传数组时，如果按值拷贝整个数组，内存和时间开销都太大。干脆只传首地址，配合你显式传的数组长度来做边界控制。
退化带来一个连锁后果：在函数内对形参使用sizeof，得到的永远是指针大小。要拿到真正的数组大小，必须在调用函数前算好，作为另一个参数传进去。这是C语言数组使用中最核心的一个“反直觉”点，我建议你直接在笔记里标红。
5.2 如何正确传数组尺寸
实际工程里有几种惯用方案，我按推荐程度说：
方案一，传数组和长度参数：
void process(int *arr, size_t len) { for (size_t i = 0; i < len; i++) { // do something } }这是C语言最经典、最可靠的传参方式。定义数组时用sizeof计算长度，调用时传进去：
int a[100] = {0}; process(a, sizeof(a) / sizeof(a[0]));方案二，用一个结构体把数组和长度包起来：
typedef struct { int *data; size_t len; } IntVec; void process(IntVec *v) { for (size_t i = 0; i < v->len; i++) { // do something } }这种封装在写动态数组、扩容、传参时很好用。本质上就是自己实现一个简单的vector容器。我记得很多人说C语言写业务麻烦，其实用这种封装之后代码会清爽很多。
方案三，用哨兵值定界。比如一个int数组约定以-1结尾，处理时读到-1就停。这个做法在解析参数表、配置项时能省掉一个长度参数，代码也简洁，但要求数据里不能出现-1这个“合法的数”，否则会提前结束。
无论用哪种方案，我发现真正的高手写C代码时有个共同习惯：操作数组前一定会确认边界条件，哪怕只是加一条if (i >= len) return;的防御语句。这不会让代码变慢多少，但能减少大量线上崩溃。
6. 数组操作的调试经验与常见崩溃排查
6.1 越界检查的笨办法
前面提过哨兵值和AddressSanitizer，这里再系统说一下我排查数组相关崩溃的完整思路。
第一反应不是看代码，而是复现。同一个崩溃如果每次位置都一样，大概率是确定的越界或野指针；如果时好时坏，多半是数据相关的越界，跟输入值、运行时状态有关。第二步，用-fsanitize=address重新编译，这个能直接定位问题行，省时省力。第三步才轮到人工静态排查：把所有循环的边界条件列出来，跟数组长度对比一遍。
数组越界最常见的三个“事故高发地”我列出来：
- 循环用<=而不是<，处理n个元素时写出了i <= n，导致最后一次访问a[n]越界；
- 字符串处理后没有在末尾补‘\0’，后续strlen读到内存深处；
- 写了arr[i][j]但实际列数与指针类型不一致，比如函数形参写int (*p)[3]，实际传进去的却是int [3][5]，每一行跳跃的步长全错了。
6.2 用断言和日志代替肉眼看
我在嵌入式项目里还习惯在关键操作前加assert断言：
#include <assert.h> void set_value(int *arr, size_t len, size_t index, int val) { assert(index < len); arr[index] = val; }assert在debug模式下有效，release模式编译时会被预处理掉，不影响性能。用它把“不可能发生但确实会发生”的边界条件显式检查出来，排查问题时能少很多脑力消耗。
日志也是排查数组问题的重要工具。我处理读文件场景（比如用C语言读Excel转数组、解析文本数据）时，习惯先把读到的数组前几个和最后几个元素打印出来。数据是从文件里读出来的，边界问题经常伴随编码问题一起出现，肉眼确认一下能快速判断是“文件数据不对”还是“数组越界”。很多文章只教你“数组转字符串”“数组方法”这些API用法，但实际项目里，能把数组内容和边界确认清楚，比多记几个API更管用。
另外一个容易被忽略的技巧是：定义数组时尽可能使用具名常量，不要满写魔数。比如：
#define MAX_ITEM_COUNT 100 int items[MAX_ITEM_COUNT]; for (int i = 0; i < MAX_ITEM_COUNT; i++) { // ... }一旦后续需要把100改成200，只改一处，不会漏掉某个循环边界导致越界。这类“防御性写法”看起来微不足道，但都是踩过坑之后长出来的经验。
写到这里想说点实际的体会。数组在C语言里说到底是“内存的视图”，你理解了连续内存、地址偏移、类型决定步长这三件事，数组的各种用法基本就通了。遇到问题不要慌，先确认数组名类型、边界值和‘\0’这三个要素。我个人习惯是每个数组相关的函数写完后，先传最小规模的数据跑一遍，再用边界值测一遍，最后才放心提交。这套习惯帮我拦下了大批潜在的数组越界bug，也分享给你。
