obj是c语言编译过程中产生的一种中间文件，中文一般叫目标文件。当你写好一个.c文件交给编译器处理时，编译器并不会一步到位生成可执行程序，而是先把源代码翻译成机器码，存放在一个obj文件里。这个文件还不能直接运行，因为它缺少一些关键信息，比如外部函数的实际地址、程序启动代码等，必须经过链接器的处理才能变成最终的.exe或者 ELF格式的可执行文件。理解obj的本质，其实是理解c语言程序从源码到可运行程序的整个构建链条。
obj文件是怎么产生的：编译的四个阶段
要弄清楚obj文件的来历，需要先了解编译器处理c代码的完整流程。整个流程通常分为预处理、编译、汇编、链接四个阶段。预处理阶段处理所有以井号开头的指令，比如头文件的包含、宏的展开、条件编译，这一步的输出还是文本形式的c代码。编译阶段把预处理后的代码进行词法分析、语法分析、语义分析和优化，生成汇编代码，此时源代码已经变成了接近机器的汇编指令。汇编阶段把汇编代码真正翻译成二进制的机器指令，输出的结果就是obj文件。
以GCC为例，可以手动控制每一步。执行gcc -c hello.c会得到hello.o，这就是obj文件，其中参数-c表示只编译不链接。如果是在Windows下使用MSVC编译器，对应生成的文件名是hello.obj。两者本质是一样的东西，只是扩展名习惯不同。
gcc -E hello.c -o hello.i # 预处理，展开头文件和宏 gcc -S hello.i -o hello.s # 编译，生成汇编代码 gcc -c hello.s -o hello.o # 汇编，生成目标文件（obj文件） gcc hello.o -o hello # 链接，生成可执行文件
把这个流程拆开执行一次，就能非常直观地看到obj文件在哪个环节出现。平时我们直接执行gcc hello.c -o hello时，这些中间文件在内存里一闪而过，没有落盘，所以很多人写了很久c语言也没亲眼见过obj文件长什么样。
obj文件里面到底装了什么
obj文件不是简单的机器码堆砌，它有自己特定的组织结构。在Windows平台上的obj文件遵循COFF格式，Linux平台上的.o文件遵循ELF格式。无论哪种格式，内部都被划分成若干个段，每个段承担不同的职责。常见的段包括text段，存放编译好的机器指令；data段，存放已初始化的全局变量和静态变量；bss段，存放未初始化的全局变量，这个段不占实际文件空间，只在加载时分配内存；rodata段，存放字符串常量和const数据。
除了代码和数据，obj文件还包含两个非常重要的信息：符号表和重定位信息。符号表记录了这个文件里定义了哪些函数和全局变量，以及它引用了哪些外部符号。比如你调用了printf，obj文件里就会有一条未解析的符号记录，表示这个函数的地址目前是未知的。重定位信息则告诉链接器，哪些位置的地址需要修正。这就是为什么单个obj文件无法独立运行：它里面引用的外部函数地址都是占位符，必须由链接器在合并多个obj文件时把真实地址填进去。
可以使用一些工具查看obj文件的内容。Linux下用objdump -t hello.o可以查看符号表，用objdump -d hello.o可以反汇编查看机器指令。Windows下如果装了Visual Studio，可以使用dumpbin /symbols hello.obj来达到类似效果。动手看一眼符号表，比读十篇文章都更能理解obj文件的本质。
objdump -t hello.o # 查看目标文件的符号表 nm hello.o # 更简洁的符号查看工具 readelf -S hello.o # 查看ELF目标文件的所有段
obj文件和可执行文件有什么区别
初学者很容易把obj文件和最终的可执行文件混为一谈，觉得都是编译的产物，应该差不多。实际上两者差别很大。obj文件只是针对单个源文件（或少数几个源文件）的翻译结果，它里面引用的外部符号没有解析，程序的入口地址也没有确定，操作系统无法把它加载执行。而可执行文件是链接器把所有obj文件、静态库、运行时库组合之后的产物，所有符号都已被解析成具体地址，还附加了操作系统加载程序所需的头部信息，比如Windows的PE头或者Linux的ELF头。
可以用一个简单的比喻来理解：obj文件像是一本书的某一章手稿，里面有引用其他章节内容的批注但还没填上页码；可执行文件则是装订完成、页码齐全、可以直接阅读的成书。链接器做的事情就是把所有手稿收集起来，统一编页码，把每处引用都改成真实的页码。
两者还有一个实际使用上的区别值得注意：obj文件的存在意义是支持增量编译。一个大项目可能有成百上千个源文件，如果每改一行代码都要重新编译整个项目，耗时会非常夸张。有了obj文件，编译器只需要重新编译被修改的那个源文件，然后重新链接所有的obj即可。链接速度远快于编译速度，这就是构建大项目时obj目录存在的价值。
常见与obj相关的链接错误
理解了obj文件的结构，很多让人头疼的报错就变得容易排查了。最经典的是undefined reference或者unresolved external symbol错误，含义是链接器在所有obj文件和库的符号表里都找不到某个符号。常见原因包括：只编译了声明所在的头文件但忘了编译实现所在的源文件；函数声明的参数类型和定义不一致导致名字修饰不同；C和C++混合编程时没有使用extern "C"导致符号名被改写。
另一个典型错误是duplicate symbol，也就是重复定义。当同一个符号在多个obj文件里都有定义时，链接器不知道该用哪一个，就会报错。典型场景是在头文件里定义了变量而不是声明变量，导致每个包含该头文件的源文件编译出的obj里都有这个变量的定义，链接时冲突。解决办法是在头文件里用extern声明，在唯一的源文件里定义，或者使用静态变量。
/* 错误写法：头文件中定义变量 */ /* util.h */ int count = 0; /* 每个 include 它的源文件都会生成一份定义，链接时重复 */ /* 正确写法 */ /* util.h */ extern int count; /* 只声明 */ /* util.c */ int count = 0; /* 唯一的定义 */
还有一个容易被忽视的问题是obj文件与编译器版本的兼容性。obj文件内部格式与编译器版本强相关，不同版本甚至不同编译器生成的obj文件往往不能混用，链接时可能报格式错误或者产生难以定位的崩溃。所以在团队协作中，通常要求所有人使用统一版本的编译器和构建环境，避免这类诡异问题。
总结一下，obj文件是c语言编译流程中承上启下的关键产物：向上承接编译器输出的机器码，向下作为链接器的输入。掌握了obj文件的生成过程、内部结构以及它与链接错误的关联，就等于掌握了c程序构建的核心脉络，再遇到链接报错时也就有了清晰的排查方向。