数据溢出是C语言里最隐蔽的一类问题：程序能编译通过，也能跑起来，但算出来的结果完全不对，甚至偶尔还会对。C语言的设计哲学是信任程序员、贴近硬件，编译器和运行时都不会替你检查一个值是否超出了类型能表示的范围，一旦超出，就发生了数据溢出。溢出带来的后果可轻可重，轻则数值回绕、符号翻转，重则程序行为不可预测，历史上不少知名的安全漏洞都和整数溢出有直接关系。想真正弄明白溢出之后会发生什么，得先回到数据在内存里的表示方式。

整数为什么会溢出：从固定位宽与补码说起

C语言中的整型变量在内存里占据固定的字节数，比如常见的char占1字节、short占2字节、int占4字节（具体宽度由编译器和平台决定）。位宽固定意味着能表示的数值个数是有限的：一个n位的无符号整数最多能表示2的n次方个不同的值，有符号整数因为要拿出一半来表示负数，正方向的最大值大约只有无符号版本的一半。一旦计算结果落在这个范围之外，硬件没有地方存放多出来的信息，只能把高位截断，或者让数值绕一圈回到另一端，这就是溢出的物理本质。

现代平台几乎都用补码来表示有符号整数。补码的好处是同一套加法器可以同时处理有符号和无符号运算，但它的取值范围是不对称的：以8位为例，范围是-128到127，负方向能到-128，正方向却只能到127。这就解释了一个经典现象，对INT_MIN取负号并不会得到一个正数，因为+128在8位补码里根本不存在，-INT_MIN的结果依然等于INT_MIN本身。理解这种不对称性，能帮你解释很多看起来反直觉的溢出结果。

下面这张表列出了常见整型在典型平台上的取值范围，写代码前心里有这张表，很多溢出问题可以在设计阶段就避开：

有符号溢出与无符号溢出：一个是未定义行为，一个是回绕

这是理解溢出后果最关键的一点：C标准对有符号整数溢出和无符号整数溢出的态度完全不同。无符号整数的运算被标准明确定义为按2的n次方取模回绕，也就是说unsigned int类型的0减1，结果确定是4294967295，任何编译器、任何平台都是这个结果，行为完全可预测。而有符号整数溢出在C标准里属于未定义行为，意味着标准对结果不做任何约束，编译器可以基于这个假设做各种激进优化，你的程序可能出现任何表现。

用一段代码看看两种溢出各自的表现：

#include <stdio.h>
#include <limits.h>
int main(void)
{
    int s = INT_MAX;
    printf("INT_MAX + 1 = %d\n", s + 1);      /* 有符号溢出，未定义行为 */
    unsigned int u = 0;
    u = u - 1;
    printf("unsigned 0 - 1 = %u\n", u);       /* 无符号回绕，输出 4294967295 */
    unsigned short len = 65535;
    len = len + 1;
    printf("unsigned short 65535 + 1 = %u\n", len);  /* 输出 0 */
    return 0;
}

在很多编译环境下，INT_MAX + 1恰好打印出-2147483648，看起来像是规律地绕了一圈，于是不少人误以为有符号溢出就是回绕。这只是补码硬件顺带产生的副作用，并不是标准保证的行为。真正的危险在于，编译器在优化时会假设有符号溢出永远不会发生，比如循环写成for (int i = 0; i <= n; i++)且内部存在i + 1之类的运算，编译器可能据此把某些分支判断直接优化掉，或者让循环表现出意料之外的形态。同一个程序换一个编译选项结果就变了，这正是未定义行为可怕的地方。

还有一个容易被忽视的坑：无符号数参与的混合运算。当int和unsigned int出现在同一个表达式中时，通常的算术转换会把int悄悄转成unsigned int。比如比较-1 < 1u，-1先被转换成4294967295，比较结果反而是假。这类隐式转换造成的伪溢出，往往比真正的溢出更难排查。

几个典型的溢出事故场景

第一种是长度计算溢出，常见于动态分配内存的代码。元素个数乘以单元素大小，如果乘积超出了size_t能表示的范围，回绕之后传给malloc的参数就变成了一个很小的数，分配成功但空间远远不够，随后的写入直接越界，这是大量缓冲区溢出漏洞的根源。

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
    /* 假设在32位平台上，size_t 最大约 4294967295 */
    size_t count = 3000000000;      /* 30亿个元素 */
    size_t elem_size = 2;           /* 每个元素2字节 */
    size_t total = count * elem_size;   /* 乘积回绕成一个较小的值 */
    printf("total = %zu\n", total);
    char *p = malloc(total);        /* 分配的内存远小于预期 */
    if (p == NULL) {
        printf("malloc failed\n");
        return 1;
    }
    /* 后续按 count 个元素写入，会造成越界访问 */
    free(p);
    return 0;
}

第二种是累加和阶乘类的数值溢出。int的阶乘到13的阶乘就已经放不下了，13的阶乘等于6227020800，远超INT_MAX的2147483647。这类代码在输入小的时候一切正常，输入一大就出诡异结果，测试阶段很容易漏掉。第三种是时间戳和计数器溢出，经典的2038年问题就是32位time_t存不下2038年之后的秒数导致的，路由器、工控设备这类长生命周期系统尤其要提前规划。

第四种藏在循环和下标运算里。用一个short做循环计数器，循环条件是小于某个大于32767的值，计数器加到32767再加1会回绕成-32768，条件永远成立，循环停不下来。数组下标经过乘加运算后再访问内存，一旦中间结果溢出，轻则读错数据，重则直接段错误。

如何检测与规避数据溢出

最直接的办法是在运算前主动预判。加法可以在计算前先检查操作数：如果两个操作数都是正数且其中一个大于INT_MAX减去另一个，就说明会正向溢出；负方向同理。把检查封装成函数，业务代码调用起来并不麻烦：

#include <stdio.h>
#include <limits.h>
/* 返回0表示成功，返回-1表示会溢出 */
int safe_add(int a, int b, int *result)
{
    if (a > 0 && b > INT_MAX - a) {
        return -1;    /* 正向溢出 */
    }
    if (a < 0 && b < INT_MIN - a) {
        return -1;    /* 负向溢出 */
    }
    *result = a + b;
    return 0;
}
int main(void)
{
    int r;
    if (safe_add(INT_MAX, 1, &r) != 0) {
        printf("检测到溢出，拒绝计算\n");
    } else {
        printf("结果 = %d\n", r);
    }
    return 0;
}

第二个思路是换更宽的类型。在32位平台上做可能超范围的乘法，可以先把操作数转成long long或者uint64_t再计算，64位能容纳的范围比32位大得多，很多业务场景下足够安全。但要注意这只是把风险推迟，64位同样会溢出，关键运算仍然要做边界检查。另外，GCC和Clang提供了__builtin_add_overflow、__builtin_mul_overflow这一族内建函数，能在指令层面完成带溢出检测的运算，性能和可读性都不错。

第三个手段是借助编译器和工具链。给GCC或Clang加上-fsanitize=undefined编译选项，运行时一旦发生有符号溢出就会立刻报告具体位置，非常适合在测试阶段扫雷。静态层面，编译器自带的-Woverflow、-Wsign-compare警告能在编译期揪出一批明显的溢出和符号转换问题，建议把警告等级开到-Wall -Wextra并保持零警告。

最后是编码习惯层面的防御：涉及长度、大小、下标的变量统一用size_t等无符号类型，避免与有符号数混用比较；对来自外部输入的数值，使用前先校验是否落在合理区间；写循环时优先用足够宽的类型做计数器。数据溢出本身往往不会让程序立刻崩溃，这种静默出错的特性才是它最危险的地方，把检查做在前面，远比事后调试省力。