“写好 C 语言的第一步，是把内存当作自己的领地去巡游。”

一、从“连续”开始：一维数组的物理世界

在 C 语言中，int arr[5] = {1, 2, 3, 4, 5}; 这行代码不仅仅是变量，更像是画在内存上的一条横线：

• 连续性：所有元素按字节顺序紧密排列，没有间隙。
• 元素大小：以 32 位编译器为例，sizeof(int) 为 4 字节，因此相邻地址差 4。
• 基址：arr 在表达式上下文中会退化为指向首元素的指针 int*，即 0x1000。

这意味着，只要你记得第一个元素的位置和元素类型大小，就能计算出任意下标的真实地址——这正是一切下标运算的根基。

二、[] 运算符的幕后故事

1. 指针算术：“加法”背后的乘法

arr + i 并不简单地把地址加上 i，而是 基址 + i × sizeof(元素类型)。编译器在生成指令时会自动乘以元素大小，无需显式乘法语句。

int value = arr[i];          // 与 *(arr + i) 等价

汇编视角（GCC -O2，x86-64 简化版）：

mov    eax,DWORD PTR [rdi+4*esi]   ; rdi 存 arr 基址, esi 存 i

可见，乘法 4*esi 已被融合进寻址模式中，零成本完成偏移计算。

2. [] 的“交换律”

令人惊讶却合乎逻辑：i[arr] 也是合法写法。由于 a[b] 被语言规范定义为 *(a + b)，交换后依旧是指针加整数。虽然没人会这么写，但它完美地揭示了下标本质是“解引用后的指针位移”。

3. 常见误解

• 数组不是指针：sizeof(arr) 得到的是整个数组大小（20 字节），而 sizeof(&arr[0]) 才是指针大小。
• 指针递增步长：p++ 针对 int* 时前进 4 字节，针对 char* 时前进 1 字节。类型决定了移动的粒度。

三、边界与未定义行为

数组边界之外是无人区，读写都会触发 Undefined Behavior（UB），最常见的后果是：

1. 意外覆盖局部变量：栈上相邻变量一并遭殃。
2. 错误的调试线索：程序崩溃点与出错点相距甚远。
3. 安全漏洞：缓冲区溢出引发可执行代码注入。

防线：

• 编译选项：-fsanitize=address、-fstack-protector-strong。
• 静态分析：clang-tidy, cppcheck。
• 单元测试：覆盖极端下标值。

四、缓存局部性与性能红利

现代 CPU 以 缓存行（Cache Line） 为单位与内存交互，常是 64 字节。顺序遍历数组时，硬件预取机制可以一次抓取 16 个 int，极大减少访存延迟。

long long sum(int *arr, size_t n) {
    long long s = 0;
    for (size_t i = 0; i < n; ++i)
        s += arr[i];          // 连续访问，命中率高
    return s;
}

与之相反，若按照跳跃步长访问（如把一维数组当二维表列优先遍历），会频繁触发 Cache Miss。因此理解内存布局不仅避免越界，更能写出高吞吐的算法。

五、栈、堆、静态区：同形不同命

• 栈数组：int arr[N]; 生命周期随函数结束即终结，大小受限（一般 <1MB）。
• 堆数组：int *arr = malloc(N * sizeof(int)); 手动管理，适合大数据结构。
• 静态/全局数组：编译期分配，常驻程序生命周期。

它们在语法上共享下标运算规则，但在调试时，地址空间分布与调试信息（如符号表）各不一样，需留意工具链的显示差异。

六、写给工程师的实战提议

1. 用 size_t 作为下标，避免符号扩展带来的隐患。
2. 封装访问接口。将越界检查与业务逻辑解耦，更易维护。
3. 利用 restrict（C99）提示编译器指针不别名，可解锁额外优化。
4. 读 disassembly。一次性理解指针加法、循环展开、SIMD——比任何教程都直观。
5. 面向缓存编程。当算法瓶颈在内存带宽时，布局比算法本身更具决定性。

七、尾声

一维数组像一条任凭你驰骋的高速公路：规则简单，却暗藏事故与捷径。深入理解它的内存布局与下标运算本质，你不仅能写出更安全、可读、易维护的代码，还能在性能的极限上多挖一寸。

拿起调试器，打印几个地址，动手感受那 4 字节的节奏——这是 C 语言教给我们的第一节“机械舞”。