C 语言内存分配（附 3 种方式），新手避坑一次讲清：从用法到排错

C 语言内存分配主要有三种方式：栈上分配、malloc 与 calloc，分别适用于大小已知、运行时才确定大小、以及需要清零的数组场景。栈分配随函数自动回收但空间受限；malloc 手动申请却不自动清零；calloc 按个数乘字节申请并自动清零。选错方式或忘记释放，就会出现内存泄漏、悬空指针和越界三类典型失败。本文先用一张对比表给出选择顺序，再用三段完整可编译示例演示每种写法的边界，最后附上内存泄漏、free 后访问、越界这三类常见失败的排查清单。读完你就能独立判断该用哪种分配、如何配对释放，并在出错时按表快速定位原因。

一、先看结论：C 语言内存分配怎么选

下面这张表直接给出选择顺序，避免你在不该用的地方踩坑。

如果你要存的数据大小编译期就确定，优先用栈上分配；大小要到运行时才知道，才上 malloc 或 calloc，并且一定记得配对 free。把「选对方式」放在第一位，是因为堆内存一旦申请就完全靠你手动管理，漏掉释放或提前访问都会留下隐患。下文每一个示例都遵循同一节奏：先申请、再检查返回值、使用、最后释放，把这个节奏固定下来能避开大部分新手错误。

二、环境确认与最小示例

写代码前先确认编译环境，能少走很多弯路。本文示例用 gcc 编译、gcc demo.c -o demo 命令运行，标准 C 库需包含 stdlib.h。如果你还在用老旧编译器，malloc 的返回类型可能需要显式强转。建议先过一遍 C 语言教程 把编译流程跑通，再回到这里复制示例。确认 gcc --version 能看到 9.0 以上版本即可，更低版本语法也兼容本文示例，不必纠结工具链细节。

下面是一段能直接编译运行的最小示例，演示 malloc 申请、检查、使用与释放：

#include <stdio.h>
#include <stdlib.h>

int main() {
    // 申请 5 个 int 的空间，malloc 返回 void*，这里强转为 int*
    int *arr = (int *)malloc(5 * sizeof(int));
    // 检查是否申请失败，堆不足时返回 NULL
    if (arr == NULL) {
        return 1;  // 失败直接退出，避免空指针解引用
    }
    // 逐个赋值并打印
    for (int i = 0; i < 5; i++) {
        arr[i] = i + 1;
        printf("%d ", arr[i]);
    }
    printf("\n");
    // 用完释放，把堆空间交还系统
    free(arr);
    return 0;
}

关于输出：本机未实际执行，按官方文档推断预期打印 1 2 3 4 5 后换行。如果编译报 malloc 未声明，先检查是否漏了 stdlib.h；如果运行崩溃，确认编译器与系统支持标准 C 库。这里要强调一个边界：malloc 在堆不足时返回 NULL 而不是抛异常，所以先判空再使用是铁律。把判空写进每个示例，比事后用调试器排查空指针更高效，这也是内存分配里最容易忽略的一步。

三、方法一：栈上分配（大小已知，随函数回收）

栈上分配最常见，局部数组和变量都在栈里，函数返回时自动销毁，不用手动释放。它的优势是零管理成本，劣势是空间小、生命周期绑定函数，无法把数据带出函数作用域。

#include <stdio.h>

// 栈上分配：局部数组，生命周期随函数，返回即失效
void print_buffer() {
    // 编译期确定大小，自动分配在栈上
    char buf[32];
    for (int i = 0; i < 5; i++) {
        buf[i] = 'A' + i;
    }
    for (int i = 0; i < 5; i++) {
        printf("%c ", buf[i]);
    }
    printf("\n");
}

int main() {
    // 调用函数，buf 在函数内创建、返回时销毁
    print_buffer();
    return 0;
}

常见失败：把 buf 的地址返回给调用者，函数结束后那块栈内存已被回收，得到悬空指针。修复方向是改用 malloc 申请堆内存，或让调用者自己传缓冲区进来。另一个容易被忽略的边界是栈空间上限，Linux 默认约 8 MB，若定义超大局部数组会直接栈溢出崩溃。把大块数据放到堆上是更稳的做法，栈只适合小且寿命短的数据。

四、方法二：malloc（手动申请，不自动清零）

malloc 从堆上要一块内存，大小运行时决定，但内容不会清零，可能是随机值。每次申请都要自己负责释放，否则就会泄漏，这是 C 语言内存分配里最高频的坑。

#include <stdio.h>
#include <stdlib.h>

int main() {
    // 申请 3 个 double 的空间，malloc 不初始化，内容随机
    double *p = (double *)malloc(3 * sizeof(double));
    if (p == NULL) {
        return 1;  // 内存不足，失败返回 NULL
    }
    p[0] = 1.1;
    p[1] = 2.2;
    p[2] = 3.3;
    for (int i = 0; i < 3; i++) {
        printf("%.1f ", p[i]);
    }
    printf("\n");
    free(p);  // 必须手动释放，否则内存泄漏
    return 0;
}

边界：malloc 返回 NULL 时一定要先检查再使用，直接解引用空指针会崩溃。申请单位是字节，记得用 sizeof 乘上元素个数，别只写元素数量。这里有个易错点：如果申请 0 字节，行为由实现定义，有的返回 NULL，有的返回可释放的空指针，不要依赖它。配对 free 时还要注意同一指针只 free 一次，重复 free 会破坏堆结构，导致后续分配全部异常。

五、方法三：calloc 与常见排错

calloc 和 malloc 一样从堆上分配，但它按「个数 × 字节」接收参数，并且会把内存自动清零，适合数组和结构体。遇到拿不准内存是否干净的场合，用 calloc 比手动 memset 更省心。也可以把示例贴到 在线代码实例 核对函数原型与输出，再按下面清单排查：

#include <stdio.h>
#include <stdlib.h>

int main() {
    // calloc(个数, 字节数)，自动把内存清零
    int *p = (int *)calloc(4, sizeof(int));
    if (p == NULL) {
        return 1;  // 失败返回 NULL
    }
    // 清零后默认值都是 0，无需手动初始化
    for (int i = 0; i < 4; i++) {
        printf("%d ", p[i]);
    }
    printf("\n");
    free(p);
    return 0;
}

排错时优先用工具而非肉眼：在 Linux 下可用 valgrind ./demo 命令检查是否泄漏，它能逐块报告未释放的内存。把 free 后置 NULL 写成习惯，可以让「释放后误用」从随机崩溃变成稳定的空指针报错，反而更容易定位。性能上，频繁申请小块内存可用内存池优化，但新手阶段先把正确性做对更重要。

总结

C 语言内存分配的核心结论很清晰：大小已知且随函数销毁用栈上分配；运行时定大小用 malloc，记得检查 NULL 并 free；需要清零的数组用 calloc。三类常见失败——内存泄漏、free 后访问、越界——都源于忘记手动管理堆。写代码时配对申请与释放、free 后置 NULL、用工具验证，就能避开绝大多数坑。建议结合编程狮的 C 语言教程，把三种写法各敲一遍再对照排错表，比只看不练记得更牢。

延伸学习

• C++ 入门课程
• C 语言避坑技巧
• GDB 速查手册

常见问题

Q：栈上分配的数组为什么不能返回指针？

A：局部数组存在栈上，函数返回后栈帧被回收，那块内存随即失效。把它的地址返回出去，调用者拿到的就是悬空指针，解引用会得到垃圾值或崩溃。需要跨函数使用就改用 malloc 申请堆内存。

Q：malloc 和 calloc 最大区别是什么？

A：两点差异最实用：一是参数形式，malloc 收总字节数，calloc 收「个数 × 字节」；二是清零行为，malloc 不初始化、内容随机，calloc 会把内存全部清成 0。只申请单个对象且要手动赋值时，用 malloc 即可。

Q：free 之后指针还能继续用吗？

A：不能。free 只是把内存交还系统，指针本身还指着那块地址，变成悬空指针。继续读写属于未定义行为，可能暂时正常也可能随机崩溃。规范做法是 free 之后立刻 p = NULL;，后续再误用会直接因空指针暴露问题。

Q：申请内存失败一定会返回 NULL 吗？

A：在标准 C 里，malloc 与 calloc 在堆不足时返回 NULL，不会抛异常，所以判空是必须步骤。但有些嵌入式或旧实现行为存在差异，稳妥写法永远是「申请后立即判空，判空后再解引用」，不要假设分配永远成功，也不要用返回值掩盖失败。