GCC 编译器这个名字，在 Linux 和嵌入式开发里几乎是绕不开的。很多人刚开始接触的时候觉得它不过是一条命令，gcc xxx.c -o xxx就完事了；可一旦手头的代码从单文件变成多文件，再变成带第三方库的工程，问题就接踵而来：头文件找不到、undefined reference、一堆 warning 不知道从哪儿下手。这篇就围绕 GCC 编译器本身，从最简单的单文件编译一路聊到多文件工程、静态库动态库和 Makefile 自动化构建，把我平时真正会用到的东西完整讲一遍。适合刚学 C/C++ 的读者，也适合那些一直依赖 IDE、想搞清楚“编译到底在干嘛”的开发同学。

1. 编译命令背后的四道工序

很多人把“编译”当作一个黑盒动作，实际上 GCC 处理一个.c文件要经过四个阶段：预处理、编译、汇编、链接。建议所有新手都亲手把四个阶段各跑一遍，因为很多玄学报错，等你理解了阶段划分，基本一眼就能定位。

1.1 预处理阶段

预处理在词法上做文本级处理。它做的事情包括：展开#include引入的头文件、处理#define宏替换、依据#if/#ifdef/#ifndef做条件编译裁剪、删除注释。举个最简单的例子，你对下面这个文件执行gcc -E：

#include <stdio.h> #define PI 3.14 int main(void) { printf("%.2f\n", PI); return 0; }

运行：

gcc -E test.c -o test.i

生成的test.i会有几百行，因为stdio.h头文件的内容被整体替换进来了，PI也变成了3.14。这一步并不会做语法检查，也不会管你的printf写法对不对，它只负责“文本替换”和“展开”。条件编译也是在这一步处理的，比如#ifdef DEBUG只在定义了DEBUG宏时才保留对应代码，一步就能裁剪出需要的内容。

提示：想快速查看某个宏预处理后的还原结果，gcc -E是最直接的。配合-D参数可以在命令行预定义宏，例如gcc -DDEBUG -E test.c，很多大型项目就是通过这种方式在编译期注入配置的。

这个小节顺带提一下头文件守卫的重要性。头文件展开这一步，正是#ifndef/#define/#endif发挥作用的地方。没有守卫的话，同一个头文件被多次 include，文本会被重复粘贴进同一个.c文件，后面等着你的就是一堆重复定义。

1.2 编译阶段

预处理产物.i进入真正的编译器前端。GCC 会做词法分析、语法分析、语义分析，把 C 代码变成语法树，再做中间代码生成和优化，最后产出汇编代码。语法错误如漏分号、括号不匹配，都是在error:提示里出现的。怎么查看这一步的结果？

gcc -S test.c -o test.s

这一步是整个四阶段里信息量最大的一步，因为它决定了你的代码质量。GCC 会做大量优化，包括常量传播、循环展开、指令选择等。这也是为什么同一段 C 代码，不同优化级别跑出来的性能能差出几倍。如果你想了解一段代码在 CPU 层面长什么样，-S生成的.s文件是很好的学习材料，汇编里的每条指令几乎都能对应回 C 源码的某个逻辑。

1.3 汇编阶段

汇编这一步用汇编器把.s翻译成机器指令，产物是.o目标文件，也叫可重定位目标文件。执行gcc -c会得到这个文件。它还没到能直接运行的状态，因为里面的函数地址、全局变量地址都没有最终确定，留了一堆“重定位信息”和“符号表”等待链接去修补。

Linux 下可以用file命令查看.o的格式，比如ELF 64-bit LSB relocatable, x86-64中的relocatable就说明它还需要被链接。很多初学者在.o和可执行文件之间划不上等号，其实一个hello.o就算你用十六进制编辑器读，也很难直接跑起来，它只是“半成品”。

1.4 链接阶段

链接器负责把多个.o文件以及你依赖的库文件合并在一起，完成符号解析和地址重定位，生成最终的可执行文件。printf是你写的吗？不是，它来自标准库。链接器就是从某个库文件里把printf的实现找出来，跟你的main.o拼在一起，或者记录下运行时从共享库加载的信息。

这里补充一个对多文件工程很重要的概念：链接器处理文件是有顺序的，这一点在后面的排查部分还会重点讲。另外静态库和动态库的差异，本质上也发生在链接阶段。把四个阶段用一张表总结一下，方便平时翻阅：

2. 单文件编译：从 hello.c 到可执行文件

先说最基础的。单文件编译是大多数人认识 GCC 的第一步，也是后面所有复杂构建的基础。很多教材只教你gcc hello.c -o hello，但并没有解释为什么要加-o。实际上，如果你直接写gcc hello.c，GCC 会默认生成一个叫a.out的可执行文件——这个名字来自几十年前 Unix 的汇编输出格式。不加-o的情况在单文件 demo 里勉强能用，在工程里就是个隐患，因为你很容易分不清哪个 a.out 是哪个程序。所以从一开始就养成习惯：gcc 源文件 -o 输出名。

2.1 最小命令与输出命名

编译命令的完整写法是gcc [选项] 源文件... -o 目标。建议把所有源文件放在中间，-o放在最后，这是大多数工程项目的惯例。如果你想生成的可执行文件名和源文件名接近，比如hello.c生成hello，直接gcc hello.c -o hello就行，没有任何歧义。唯一要注意的是，如果目录里已经有一个叫hello的文件夹，GCC 会直接报错，提示目标是个目录。这种情况在工程混排的目录结构里经常遇到，删掉同名文件夹或者换一个输出名就行。

一个容易被忽略的细节是，GCC 会根据源文件的扩展名决定编译方式。.c文件按 C 处理，.cpp、.cc文件按 C++ 处理。所以如果你把一个 C++ 源码命名为main.c，并用 gcc 编译，会碰到一堆语法错误；反过来，你用 g++ 去编译纯 C 代码，大多也能通过，因为 g++ 会把.c也当 C++ 处理。这个细节经常让刚接触多语言混编的人抓狂。

2.2 调试、警告、优化三件套

单文件编译真正要掌握的不是那一行最短命令，而是三个核心参数：-g、-Wall、-O系列。

-g的作用是生成调试信息。没有它，GDB 就无法把运行地址映射回源代码行号，你断点打在printf那行，GDB 却一脸懵。调试阶段务必加上。-Wall的作用是打开大部分警告，比如未使用变量、隐式函数声明、类型不匹配等。我见过太多同学写的代码能通过编译但隐藏着一堆隐患，就是因为他们只看 error 不看 warning。一个负责任的项目通常会把-Wall -Wextra当成默认项，有的甚至加-Werror把警告直接升级为错误。个人建议：刚开始练习的时候不要上-Werror，否则你会被警告淹没；等你能理解每条警告的含义了，再考虑把它加入 CI 流程。

-O系列控制优化级别。-O0不优化，编译最快，调试最舒服；-O1做基础优化；-O2是发布常用的优化级别；-O3更激进。还有-Os偏向生成小体积代码，-Og是在调试体验和优化之间取平衡。对初学者，我的建议是不要碰优化级别，默认的-O0就行。如果哪天你发现同样的代码，开优化后运行结果变了，先别怀疑编译器的 bug，大概率是你代码里有未定义行为，比如数组越界、整数溢出、悬空指针。这类问题在-O0下往往还能“侥幸运行”，在-O2下就可能原形毕露。

顺带提一个和 C 标准相关的参数-std=c11/-std=c17/-std=gnu11。指定标准影响语言特性，比如循环变量声明、复合字面量等。默认情况下 GCC 会使用带 GNU 扩展的某个标准版本，对初学者影响不大，但等你要把代码移植到其他编译器时，建议显式指定标准。

2.3 控制编译步骤的三个选项

第一章讲了四阶段，对应到实际命令就是三个选项：-E、-S、-c。我不建议把它们当成需要背的参数，而是当成“调试编译过程”的工具。当你想知道某个宏展开成了什么，-E是你的放大镜；当你想看编译器生成的汇编质量，-S是你的解剖刀；当你想给多个源文件分别生成中间产物，-c是先编译不链接的标准姿势。

很多所谓的“编译失败”其实不是 GCC 的问题，而是你对阶段的理解出了问题。比如报错信息里出现undefined reference to xxx，这说明前面的.o生成没问题，问题出在链接阶段；报错信息里出现expected ';' before '}'，这是编译阶段的语法错误，跟链接没有任何关系。分清阶段，你排查问题的范围直接缩小一大半。

我在日常开发中，几乎不会单独敲-E和-S，但-c是天天用的，因为主流构建系统都是把编译和链接分开做。多文件工程里，每个.c先各自编译成.o，最后再统一链接，这正好是下一节要展开的内容。

3. 多文件工程：从手动批量编译到库的封装

多文件工程之所以存在，是因为没人愿意把几千行代码写进一个文件。当你有main.c、util.c、file.c三个源文件时，最直接的编译方式就是：

gcc main.c util.c file.c -o app

这条命令内部做的事情是：分别对三个源文件做预处理、编译、汇编，得到三个.o，再一次性链接成可执行文件app。看起来很简单，但它有个致命问题：每次改动任意一个文件，所有源文件都会重新编译。项目小的时候无所谓，项目大了之后，一次增量改动可能就要等好几分钟甚至十几分钟。这就是需要分步编译的原因。

分步编译的思路是把“编译”和“链接”分开：

gcc -c main.c gcc -c util.c gcc -c file.c gcc main.o util.o file.o -o app

这样改main.c只需要重新编译main.c，再链接一次，另外两个.o完全不用动。这一步看似只是把命令拆开，实际上是所有主流构建系统（Make、Ninja、CMake 的底层）的核心逻辑：增量编译。我见过有人直接写一个 shell 脚本把所有gcc -c命令存起来，实现“伪增量”，这其实就是在手工造一个简陋的 make。后面我会讲更优雅的 Makefile 方案，但在此之前，请先亲手把分步编译跑一遍，理解.o的生成和复用。

3.1 头文件的正确组织方式

多文件工程避不开头文件。头文件放声明，源文件放定义，这是一条基本纪律。比如我们写一个util模块：

util.h：

#ifndef UTIL_H #define UTIL_H int add(int a, int b); int multiply(int a, int b); #endif

util.c：

#include "util.h" int add(int a, int b) { return a + b; } int multiply(int a, int b) { return a * b; }

main.c：

#include <stdio.h> #include "util.h" int main(void) { printf("%d\n", add(2, 3)); return 0; }

先说#ifndef UTIL_H这一组，它叫头文件守卫。作用是在同一个编译单元内，防止util.h被重复展开。没有它，如果util.h又被other.hinclude，而main.c同时 include 两个头文件，函数声明就会重复出现。另一种等价写法是#pragma once，主流编译器都支持，但老项目里头文件守卫更常见。

再看包含方式。#include <stdio.h>用的是尖括号，GCC 会到系统头文件目录找，比如/usr/include；#include "util.h"用的是双引号，GCC 会先从当前源文件所在的目录找，找不到再走系统路径。所以同目录下的自定义头文件用双引号就能找到。如果头文件放在include子目录，你需要在编译命令里加-I搜索路径。比如典型的三级目录结构：

project/ ├── src/ │ ├── main.c │ └── util.c ├── include/ │ └── util.h └── Makefile

编译命令变成：

gcc -Isrc -Iinclude src/main.c src/util.c -o app

严格来说-Isrc不写也能找到src/下的头文件，但-Iinclude是必须的，否则双引号方式只会从src/找，include/util.h就会被漏掉。这里有一个经常犯的错误：把-I拼写成-i，小写-i在 GCC 里是别的用途，报错会很莫名其妙，我当年就踩过这个坑。

一个工程越做越大，头文件管理就越重要。建议尽量让头文件自包含，也就是每个头文件都能独立被 include，不依赖别的头文件的“前置 include”顺序，否则排查依赖问题会非常痛苦。

3.2 静态库：把编译结果打包归档

多文件工程做到一定规模，你会发现有些模块是可以复用的，比如加密算法、字符串处理、网络协议。总不能每用一次就把源码拷一份进来参与编译，既占空间又拖慢构建。这时候就该把一组.o打包成“库”。

静态库在 Linux 下就是一个用ar工具打包的.a归档文件，本质是若干.o文件的集合。制作步骤两步走：

gcc -c util.c -o util.o ar rcs libutil.a util.o

ar rcs里的r是把文件插入归档，c是创建归档（如果不存在），s是建立索引，方便链接器快速查找符号。如果你的模块有多个源文件，就先把它们全部编译成.o，一次性归档：

gcc -c util_a.c -o util_a.o gcc -c util_b.c -o util_b.o ar rcs libutil.a util_a.o util_b.o

使用静态库时的链接命令长这样：

gcc main.o -L. -lutil -o app

注意几个命名规则：库文件必须叫lib+ 库名 +.a，所以libutil.a对应的库名是util；链接参数里用-l加库名（不加lib前缀和.a后缀）；-L.告诉链接器在当前目录找库。如果你把库放在/opt/mylib/lib，就写成-L/opt/mylib/lib -lutil。

静态库最大的特点是链接时会把需要的代码直接拷贝进可执行文件。发布时只要带上可执行文件就行，不依赖额外的.a文件。缺点是多个程序共享同一份代码时，每个程序都有一份拷贝，浪费磁盘和内存，而且库更新时必须重新链接所有依赖它的程序。这就是动态库出现的背景。静态库链接顺序需要特别注意，这一点后面排查部分会重点讲，先在这里埋个伏笔：-lutil放在命令行哪个位置，直接决定了能不能链成功。

3.3 动态库：共享代码的另一条路

动态库也叫共享库，Linux 下扩展名是.so。和静态库不同，它不会在链接时把代码拷贝进可执行文件，而是把“引用关系”记录下来，程序运行时再由动态链接器加载。

制作动态库一行命令：

gcc -fPIC -shared -o libutil.so util.c

这里-fPIC生成位置无关代码，是共享库必需的；-shared告诉 GCC 生成共享库而不是可执行文件。使用动态库的编译命令和静态库长得一模一样：

gcc main.o -L. -lutil -o app

但运行./app时往往会碰到error while loading shared libraries: libutil.so: cannot open shared object file: No such file or directory。因为系统找不到libutil.so。临时解决办法是设置环境变量：

export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./app

更稳妥的做法是把库放到系统搜索路径之一（如/usr/local/lib），再执行ldconfig刷新缓存。不过对于学习或小规模内部工具，LD_LIBRARY_PATH足够用了。

动态库的优势是多个程序共享同一份代码，节省内存；库可以单独升级，不用重新编译所有程序。劣势是依赖管理复杂，经典的“库不兼容”问题大多由此而来。如果同一个库在系统里有多个版本，光靠环境变量排查就够喝一壶的。另一个让初学者迷惑的现象是：明明用了-lutil链接，GCC 怎么知道要选静态库还是动态库？规则是：如果libutil.a和libutil.so同时存在，默认优先选择动态库，除非你加-static强制静态链接，或者用-Wl,-Bstatic对某个库单独指定。

4. Makefile：把多文件编译变成系统化工程

命令越拆越多，人肉管理.o就开始不靠谱了。这时候 Makefile 登场。Makefile 是make工具的脚本，核心是一个个规则，每条规则由三部分组成：目标、依赖、命令。

4.1 最小可用 Makefile

最简单的多文件工程 Makefile：

app: main.o util.o gcc main.o util.o -o app main.o: main.c util.h gcc -c main.c -o main.o util.o: util.c util.h gcc -c util.c -o util.o clean: rm -f app main.o util.o .PHONY: clean

保存为Makefile，然后在该目录执行make即可。make的默认目标是第一条规则的目标，也就是app。它会检查app是否存在，以及它的依赖main.outil.o是否比它新——如果.o文件更新，说明源文件改动过，需要重新链接；同理，main.o依赖main.c util.h，如果util.h被改过，make也会知道需要重新编译main.c。这就是增量编译的魔法，靠的就是文件时间戳。

写 Makefile 最容易犯的错是：规则下面的命令必须用 Tab 开头。四个空格、空格排版、别的缩进统统不行。很多新手第一次在编辑器里写 Makefile 就死在这条规则上，make会报missing separator。有个取巧的办法：如果你必须用空格缩进，可以在编辑器里设置“让 Tab 键输出真正的 Tab 字符”，并全部用于规则行。.PHONY: clean的意思是clean是一个伪目标，不代表真实文件。不加它也能用，但如果目录里恰好有一个叫clean的文件，make clean就会因为“文件已是最新”而什么都不干，很让人困惑。加上.PHONY是标准做法。

4.2 变量和模式规则：告别重复代码

上面的 Makefile 里每个.o都手写了规则，文件一多就开始啰嗦。用变量和模式规则精简。变量先声明后使用，$(变量名)引用：

CC = gcc CFLAGS = -Wall -Wextra -g OBJS = main.o util.o app: $(OBJS) $(CC) $(CFLAGS) -o $@ $(OBJS) %.o: %.c $(CC) $(CFLAGS) -c $< -o $@ clean: rm -f app $(OBJS) .PHONY: clean

这段比之前清爽多了。CC是编译器，CFLAGS是编译参数，OBJS是目标文件列表。模式规则%.o: %.c表示“所有以 .o 结尾的文件，都从同名 .c 编译而来”，只要依赖关系满足，make 会自动用这条规则处理main.o和util.o。头文件依赖还没写进去，我们稍后处理。

$@、$<、$^是自动变量：$@代表目标名，$<代表第一个依赖名，$^代表所有依赖名。命令$(CC) $(CFLAGS) -c $< -o $@展开后就是gcc -Wall -Wextra -g -c main.c -o main.o。这样无论新增多少源文件，Makefile 主体基本不用改，只需往OBJS里追加文件名。

4.3 头文件依赖和自动更新依赖

模式规则虽然解决了重复代码问题，但还有一个隐患：%.o: %.c只依赖同名.c文件，不关心头文件。如果util.h被改动了，make根本不会重新编译util.c，因为它的规则里没写util.h作为依赖。这就会导致旧.o+ 新头文件的组合，编译期不报错，链接出来的程序行为却不对，极其难排查。

最传统的解法是在规则里手动声明头文件依赖：main.o: main.c util.h、util.o: util.c util.h。但头文件关系一多就维护不过来。更现代的方案是利用 GCC 的自动依赖生成选项-MMD搭配-MP：编译的同时生成一个与.o同名的.d文件，里面记录了当前源文件的所有头文件依赖。在 Makefile 里用-include把这些.d文件引入即可：

CC = gcc CFLAGS = -Wall -Wextra -g -MMD OBJS = main.o util.o DEPS = $(OBJS:.o=.d) app: $(OBJS) $(CC) $(CFLAGS) -o $@ $(OBJS) %.o: %.c $(CC) $(CFLAGS) -c $< -o $@ clean: rm -f app $(OBJS) $(DEPS) -include $(DEPS) .PHONY: clean

DEPS = $(OBJS:.o=.d)是变量替换，把main.o换成main.d。-include $(DEPS)的意思是：如果.d文件存在就 include 进 Makefile。首次编译时没有.d文件，没关系；第二次编译时.d文件生成了，里面写着类似：

main.o: main.c /usr/include/stdio.h util.h

以后只要你改util.h，main.o就会被判定为过期并触发重编译。这套方案我用了很多年，比手写依赖列表可靠得多，推荐直接抄作业。

5. 编译报错与排查实录

编译链接都报错是家常便饭，但很多问题翻来覆去就那几类。我把高频错误和排查思路整理成一套“速查本”，遇到可以直接对号入座。

5.1 undefined reference：最让人头痛的链接错误

undefined reference to 'add'堪称多文件工程第一大报错。这说明编译阶段已经通过，.o文件也生成了，但链接器在链接时找不到add这个符号的实现。

典型原因有四种：一是函数只声明没定义，比如在头文件里写了int add(int a, int b);，却忘了在某个.c里正式实现；二是实现的文件没参与链接，比如链接命令里漏了util.o；三是实现写在某个静态库里，但你没加-L和-l；四是链接顺序问题，这是最隐蔽的。

链接顺序问题值得单独说。GCC 处理命令行中的目标文件和静态库时，是从左到右依次扫描的。链接器在扫描到某个.o文件时，会把这个文件需要的未定义符号记下来，然后继续往后扫，直到在某个库或.o里找到定义才消掉记录。如果遇到静态库但当前没有等待解析的符号，这个库即便有定义后续也不会再被回头查找。写成命令就是：

gcc -lutil main.o -o app # 大概率链接失败 gcc main.o -lutil -o app # 正常

第一行里-lutil出现在main.o前面，链接器扫描libutil.a时还不知道main.o需要add，就没从这个库里提取任何东西；等扫描到main.o发现有未定义符号，库已经“错过”了。所以静态库要尽量放在命令行后面，依赖库的源文件要放在库前面。这条经验在 CMake 里同样成立，只是 CMake 帮你处理了大部分顺序。

排查时可以先用nm查看.o或库里有没有对应符号：nm util.o | grep add。符号存在，说明实现没参与链接；符号不存在，说明实现压根没有编译进去。nm是排查链接问题最趁手的工具，比瞎猜高效得多。

5.2 multiple definition：重复定义大战

multiple definition of 'xxx'是另一个高频链接错误。它说的是同一个符号在多个编译单元里都有定义。

最常见的场景是：头文件里定义了全局变量或函数体。如果util.h里写int global_var = 0;，而main.c和util.c都 include 了这个头文件，预处理阶段两个.c文件里就各有一个global_var的定义，链接时自然冲突。函数同理，虽然static inline可以缓解，但普通函数定义放头文件里，多 include 几次就炸。

解决办法：头文件只放声明，把定义放到且只放到一个源文件里。如果确实希望一个变量在整个工程共享，就在头文件里声明extern int global_var;，在某个.c文件里定义一次。这里有个对应的诡异现象：多个定义报错，很多人的第一反应是检查 include 是不是重复了，其实跟 include 次数无关，include 守卫只保证同一编译单元内不重复，链接阶段照样能看到不同.o里的重复符号。先理解这点，就不会浪费时间去调#ifndef。如果两个.o里的重复符号是历史遗留，没法立刻合并，可以临时把其中一个的定义加上static，让它的作用域限制在本编译单元内。但这只是权宜之计，长期还是应该理清模块边界。

5.3 头文件找不到：搜索路径排查法

fatal error: util.h: No such file or directory属于预处理阶段的报错，意味着 GCC 在它的头文件搜索路径里找不到这个文件。

排查思路按顺序走：先确认文件真实存在，再确认路径写对了。如果头文件跟源文件同目录，双引号 include 理应找得到，找不到就要先怀疑是不是文件名大小写、后缀名错了。如果头文件在include子目录，检查编译命令里有没有-Iinclude。如果写的是#include "include/util.h"，那-I参数要指向include的上一级目录，因为 GCC 会把双引号里的路径跟搜索路径拼起来。还有一种情况是系统标准头文件找不到，比如stdio.h不见了，那基本是工具链配置或者环境不完整，检查环境变量CPATH、C_INCLUDE_PATH有没有被改坏。

很多人容易忽略/usr/include这种系统路径只对标准库有效，你自己的工程头文件最好一律通过-I明确指定，不要指望 GCC 默认能找到。工程目录结构清晰 + 编译命令里路径写全，头文件问题能少掉一大半。

5.4 编译通过但运行崩溃：常见运行时翻车

编译链接都通过，程序一跑就段错误（Segmentation fault），这是从“编译器”话题延伸到“调试”的问题，但既然多文件工程必然遇到，简单说一点。段错误多数是访问了非法内存，比如数组越界、解引用空指针、使用未初始化的指针，或者函数参数类型不匹配导致调用约定崩坏。

建议动手之前，先确认编译命令带上了-g，然后启动 GDB：

gcc -g -Wall -Wextra main.c util.c -o app gdb ./app (gdb) run (gdb) bt

bt打印调用栈，能直接看到崩溃发生在哪个函数、哪一行。配合行号定位，多数情况一眼就知道问题在哪儿。还有人会遇到“加减乘除突然算错”或“开优化后结果不一样”，这往往是代码里藏着未定义行为（UB），比如有符号整数溢出、访问越界内存。编译器不保证 UB 的任何行为，-O2下出现诡异结果并不奇怪，先用-O0跑一遍，再用-fsanitize=address,undefined重新编译，能帮你在运行期抓到绝大多数越界和 UB 现场。-fsanitize这套工具是我最近几年才习惯用的，真是相见恨晚。

6. 一点个人体会

这么一路说下来，你可能也发现了，GCC 本身并不神秘。四道工序、三个单步选项、一大串参数背后，都是围绕“把源码变成可执行文件”这个目标服务的。我自己的体会是，与其死记命令，不如先理解阶段，再理解场景。看到undefined reference知道去查链接；看到头文件找不到，知道去查搜索路径；看到编译通过但行为诡异，知道去查 UB。这个排查链路比任何参数合集都值钱。

如果你现在正被多文件工程折磨，我的建议是先别急着上 CMake，亲手写一次 Makefile、编译一次静态库、链接一次动态库，把手工流程完整走一遍。这些底层的构建逻辑，迟早会在某个排查之夜帮上大忙。GCC 的文档永远在那里，但只有亲手踩过坑，才知道哪些坑最值得绕开。