编译器如何处理多个源文件
写一个程序，尤其是稍大一点的项目，很少会把所有代码塞进一个文件里。就像做饭不会把所有食材全扔进一个碗里一样，代码也得分类放好。常见的做法是把功能拆开，比如把主逻辑放在 main.c，把工具函数放在 utils.c，再把声明集中到头文件 utils.h。这时候问题就来了：编译器是怎么把这些分散的文件拼起来，最终生成一个可执行程序的？
分步走：预处理、编译、汇编、链接
编译器并不是一口气把所有 .c 文件读进来直接变出 exe 或可执行文件。它走的是流水线作业。以 GCC 为例，整个过程分成四步：预处理、编译、汇编、链接。
先说预处理。这一步主要处理 #include、#define 这些宏指令。比如你在 main.c 里写了 #include "utils.h"，编译器就会把 utils.h 的内容原封不动地“复制”进去。相当于在开工前先把图纸拼完整。
接下来是编译阶段。每个 .c 文件会被独立翻译成对应的汇编代码。main.c 变成 main.s，utils.c 变成 utils.s。这个过程是彼此隔离的，互不干扰。也就是说，即使两个文件用了同名但不同义的变量，只要不在同一个编译单元里，就不会立刻出错。
然后是汇编。把 .s 汇编文件转成二进制的目标文件，也就是 .o（Linux/Unix）或 .obj（Windows）。这些文件里存的是机器码，但还不能直接运行，因为它们可能依赖其他文件里的函数或变量。
链接：把碎片拼成整体
真正让多个源文件“认亲”的，是最后的链接阶段。比如 main.c 里调用了 utils.c 中定义的 int add(int a, int b)，编译 main.o 的时候，编译器只知道 add 是个外部符号，并不知道它在哪。直到链接器出场，它会扫描所有目标文件，发现 main.o 要找 add，而 utils.o 正好提供了这个符号，于是就把它们“缝”在一起。
如果某个函数声明了却没定义，链接器就会报错：undefined reference。这就像你写了个借条说要还钱，但没人见过你真还，系统就不认这笔账。
实际操作示例
假设有三个文件：
// main.c
#include <stdio.h>
#include "utils.h"
int main() {
int result = add(3, 5);
printf("结果：%d\n", result);
return 0;
}// utils.h
int add(int a, int b);// utils.c
#include "utils.h"
int add(int a, int b) {
return a + b;
}你可以这样编译：
gcc -c main.c // 生成 main.o
gcc -c utils.c // 生成 utils.o
gcc main.o utils.o -o program // 链接成可执行文件也可以一步到位：
gcc main.c utils.c -o program后一种写法看起来简单，其实背后还是走了一遍“分别编译、统一链接”的流程。
头文件的作用不只是声明
头文件的存在，就是为了在多个源文件之间共享声明。比如 utils.h 被 main.c 和另一个 test.c 同时包含，就能确保大家对 add 函数的理解一致。没有它，每个文件都自己猜参数和返回值，迟早出乱子。
另外，为了避免重复包含，通常会在头文件里加“守卫”：
#ifndef UTILS_H
#define UTILS_H
int add(int a, int b);
#endif // UTILS_H这样即使被多次 include，也不会重复定义，防止编译出错。
大型项目中的常见做法
在真实开发中，项目动辄几十上百个源文件。没人会手动敲 gcc 命令。这时候会用 Makefile 或 CMake 来管理编译流程。它们的核心思路不变：先把每个源文件单独编译成目标文件，最后统一链接。
这种机制还有一个好处：如果你只改了 utils.c，重新编译时可以只重新编译这个文件，main.c 对应的目标文件不用动，节省时间。就像修车时只换坏掉的零件，不用整车重造。