企业官网建设流程全解析

开工之前先问一个问题：你写代码的时候，是不是也经历过这种状态——改了项目里的一个 .c 文件，然后为了验证效果，把那一长串 gcc 命令从历史记录里翻出来，复制、粘贴、回车，接着发现报错说少了个头文件路径，于是加上 -I 再来一次；好不容易编译过了，又想起还有另一个测试文件要一起编，于是把命令改一改，再跑一遍。项目文件少的时候，这套“手工小作坊”流程还能扛得住；一旦文件上了两位数、依赖关系开始交叉，你大概率会开始怀疑人生：我到底有没有漏编译哪个文件？刚才那个目标真的更新了吗？为什么改了个头文件，整个项目像没看见一样？

这时候，你就需要 Makefile 了。

作为一个 Linux 开发绕不开的基础工具，Makefile 的本质就是一个“自动化工厂的排产表”：你告诉它工厂里有哪些产品（目标文件）、每个产品需要哪些原料（依赖文件）、用什么机器怎么加工（命令），它就能自己判断哪些工序需要重跑、哪些可以跳过，还能并行开工、统一清理。这篇文章我会从手工编译的痛点讲起，拆解 Makefile 的核心语法和设计思路，再用一个完整的 C 项目把从零到能用的过程走一遍，最后整理我在实际开发中踩过的高频坑。文章适合刚接触 Linux 开发、或者写过一点 C/C++ 但一直对 make/makefile 半懂不懂的读者，也会给已经在用、但想搞懂“为什么这么写”的人一些参考。

1. Makefile 到底解决了什么问题：从“每次全量重来”到“按需增量构建”

1.1 手工编译的真实痛点：一个会呼吸的痛

先还原一个场景。假设你正在写一个小型 C 项目，目录结构长这样：

project/ ├── main.c ├── utils.c ├── utils.h ├── calc.c ├── calc.h └── Makefile

main.c 调用了 utils.c 和 calc.c 里的函数，utils.c 又引用了 calc.h 里的宏定义。第一版编译命令大概是这样的：

gcc -Wall -o app main.c utils.c calc.c

看起来挺简单对吧？可一旦你开始加功能，痛点就来了。

• 命令越攒越长：文件从 3 个变成 10 个、20 个，这条 gcc 命令本身就成了“阅读障碍物”。
• 全量编译浪费时间：你只是改了 calc.c 里的一个函数实现，结果 20 个文件全部重新编译链接。编译慢的时候，每次等这几秒几十秒都是折磨，大型项目甚至是几分钟起步。
• 依赖关系靠脑子记：哪个 .c 文件依赖哪个 .h，谁改了要重编谁，完全靠记忆。头文件一改，常常忘了某些 .c 需要重编，最后链接出一堆奇怪错误，比如 “undefined reference” 或 “incompatible type”。
• 清理和重建没有统一入口：想完全干净地重编一次？你得先手动 rm 掉所有 .o 文件，或者干脆把整个目录删了重来。

这些痛的本质是什么？缺少一个“能感知变化、只做必要工作、且把步骤固化下来”的自动化构建脚本。Makefile 就是来解决这个问题的。

1.2 增量编译与依赖管理：Makefile 的核心价值

Makefile 的底层逻辑其实特别朴素：它维护了一张“依赖图谱”，每个目标文件（target）记录了它依赖哪些文件（prerequisites），以及当依赖发生变化时应该执行什么命令（recipe）。每次执行 make 时，它做三件事：

1. 检查目标文件是否存在。
2. 如果存在，比较目标和所有依赖的时间戳（mtime）。
3. 只要有任何一个依赖比目标新，就重新执行对应的命令。如果所有依赖都比目标旧，什么都不做，直接跳过。

这就是增量编译。你改了 calc.c，make 发现 calc.o 比 calc.c 旧，于是只重新编译 calc.c 生成新的 calc.o，然后重新链接一次 app，其他文件的原样复用。整个流程完全由 make 自动判断，你不需要关心“哪个改了要重编哪个”，只需要维护好规则里的依赖关系。

用生活类比就是：做一顿饭，上次备好的菜（.o 文件）还能用就不重新切，只有你新买回来的菜（改动过的 .c 文件）需要处理，最后统一上锅炒（链接）。省时省力，而且不容易出错。

除了增量编译，Makefile 还顺手解决了好几件事：

• 环境一致性：同一份 Makefile，交给任何人、在任何 Linux 机器上，跑出来的构建流程都一样，告别“在我电脑上能编，到你那儿就不行”的玄学。
• 并行构建：一条make -j4就能让多个互不依赖的编译任务同时跑，多核 CPU 利用率直线上升。
• 统一的入口：build、clean、install、test 这些目标写好后，团队协作只需要约定“make”和“make clean”，不用每个人记一套命令。

1.3 什么场景真的需要 Makefile

很多新手会有个疑惑：现在 IDE 不都能一键编译吗？我干嘛还要学 Makefile？

这里要分场景看。如果你只是用 IDE 写单个文件的小练习，确实没必要碰 Makefile。但一旦涉及下面几种情况，Makefile 就是刚需：

• 命令行环境：服务器、嵌入式开发板、Docker 构建过程中，没有图形界面，一切靠命令行。你总不能每次都在 IDE 里点按钮吧。
• 交叉编译：嵌入式 Linux（比如 RK 平台的 RV1106、全志系列、树莓派）开发中，要用交叉编译工具链编译出能在 ARM 板子上跑的程序，编译参数复杂、路径特殊，Makefile 能把工具链、头文件路径、库路径固化下来，避免一遍遍手动敲一大串 --sysroot、-I、-L 参数。
• 开源项目：大量 C/C++ 开源项目（Linux 内核、busybox、很多工具链）都是 Makefile 驱动的。你想给这些项目加功能、改配置，不懂 Makefile 连编译都跑不起来。
• 自动化流水线：CI/CD 里经常要跑make build、make test，这已经是约定俗成的标准接口了。

说白了，Makefile 是 Linux 下“构建自动化”这门手艺的基本功。CMake 虽然现在很流行，但它生成出来的东西归根结底往往还是 Makefile（也可以生成 Ninja 文件）。把 Makefile 搞懂了，你再看 CMake、Meson 这些上层工具，会有一种“底层逻辑通了”的感觉。

2. 核心语法拆解：规则、变量、自动变量与隐含规则

2.1 一条规则的三要素：目标、依赖、命令

Makefile 最基本的单元是“规则”，格式长这样：

目标: 依赖... <TAB> 命令

注意，第一：命令前面必须是一个TAB 字符，不能用空格代替。这是新手最容易踩的坑，missing separator这个报错十有八九就是用了空格。第二：命令是交给 shell 执行的，所以你可以写任何 shell 命令，包括 gcc、rm、echo 等等。

一个最简单的例子：

app: main.c utils.c calc.c gcc -o app main.c utils.c calc.c

意思很清楚：app 依赖于这三个 .c 文件，一旦任何一个比 app 新，就执行 gcc 命令重新生成 app。但你在实际工程里一般不会这么写，因为这种写法没有中间产物 .o，每次 main.c 变化，所有文件都得重新编译一遍，增量编译的红利一点没吃到。

所以工程上通常会把编译拆成两步：先生成 .o 目标文件，再链接成最终可执行文件。于是规则就细化成：

app: main.o utils.o calc.o gcc -o app main.o utils.o calc.o main.o: main.c utils.h calc.h gcc -c -o main.o main.c utils.o: utils.c utils.h calc.h gcc -c -o utils.o utils.c calc.o: calc.c calc.h gcc -c -o calc.o calc.c

这样改 main.c 只会重编 main.o，然后重新链接；改 calc.c 只会重编 calc.o。头文件的变化也能被感知到，因为每个 .o 都列出了它依赖的 .h。

在这个基础上，make 在找不到某个 .o 的时候，还会自动往下找有没有生成它的规则——这就是 make 的“递归推导”。比如你执行 make app，它发现 app 依赖 main.o，而 main.o 当前不存在，就会寻找 main.o 的规则并先执行。这种“按需推导”和“时间戳判定”加在一起，就构成了自动化的核心机制。

2.2 变量与自动变量：让 Makefile 不再重复

写久了你会发现，纯手工一条条写规则也是有问题的：文件一多，规则里全是重复内容，改个编译器选项得改几十行。这时候就该上变量了。

Makefile 里变量定义很简单：

CC = gcc CFLAGS = -Wall -g OBJS = main.o utils.o calc.o TARGET = app

使用变量用$(变量名)：

$(TARGET): $(OBJS) $(CC) $(CFLAGS) -o $(TARGET) $(OBJS)

这样一来，想换编译器、加编译选项，只改赋值那一行就够了。变量定义有几个运算符，要注意区别：

• =：递归展开式赋值。引用的变量在真正使用时才展开，可能导致意外的递归循环。
• :=：立即展开式赋值。赋值时就把右边的变量展开掉，更直观，推荐优先使用。
• +=：追加赋值。给已有变量追加内容。
• ?=：如果变量没定义过才赋值，常用于允许命令行覆盖默认值。

实际写作中，我和周围同事的习惯是默认用:=，只有确定要用=的延迟展开特性时才换。因为递归展开的坑太隐蔽了，调试起来很头疼。

自动变量也是高频利器。常见的几个：

有了自动变量，你可以把上面的规则写得更通用：

%.o: %.c $(CC) $(CFLAGS) -c -o $@ $<

这里的%是模式匹配符。%.o: %.c的意思是：任何一个 .o 文件，都是通过把 .c 文件名里的 .c 换成 .o 得到的对应 .c 文件编译出来的。命令里的$@自动变为当前目标名，$<自动变为对应的 .c 文件。这一招把原来一大堆绕来绕去的 .o 规则压缩成了一行，Makefile 的“自动化工厂”气质一下子就出来了。

$^则适合链接场景：

$(TARGET): $(OBJS) $(CC) -o $@ $^

不用再手写一长串 .o 文件列表。

2.3 伪目标 .PHONY：防止“重名文件”的幽灵

有个很经典的坑：你写了一个 clean 目标，命令是rm -f *.o $(TARGET)，正常情况下make clean能正常执行。但如果哪天你的目录下真的出现了一个名为 clean 的文件——比如有人手滑touch clean——make 发现目标 clean 已经存在且没有依赖，就会判定“目标已是最新”，什么都不做。这直接把人整懵。

解决办法就是声明伪目标，告诉 make“这个目标不代表真实文件，每次都要执行命令”：

.PHONY: clean all install test clean: rm -f *.o $(TARGET)

所有不代表真实文件的目标，比如 all、clean、install、test，都建议加上 .PHONY 声明。这是 Makefile 工程化的基本素养之一。

再补充一个细节：当 Makefile 里定义了all目标时，惯例上将它作为第一个目标，因为 make 默认执行第一个目标（不指定目标名时）。所以你通常会看到：

all: $(TARGET) @echo "build done"

把 all 放在最前面，让默认行为变成“构建整个程序”。

3. 从零搭建一个完整项目的 Makefile：实操全流程

理论说再多，不如自己动手跑一遍。这里我拿一个稍微真实点的项目来演示：一个简单的成绩统计程序，包含主程序、文件读取模块、统计模块和公共头文件。我会从第一版最简单的写法开始，逐步改成工程化可用的版本。

3.1 项目结构与需求定义

假设项目目录是score_stat/，结构如下：

score_stat/ ├── main.c ├── file_io.c ├── file_io.h ├── stats.c ├── stats.h ├── common.h └── Makefile

功能模块划分：

• common.h：公共类型定义和宏，比如MAX_NAME_LEN、MAX_STUDENTS。
• file_io.h/.c：从文本文件读取学生成绩数据，返回结构体数组。
• stats.h/.c：计算平均分、最高分、最低分、及格率等统计指标。
• main.c：调用上面两个模块，输出结果。

所有模块都用 C 编写，编译成一个可执行文件score_app。目标平台是普通 Linux PC，编译器用 gcc，后续可以很容易改成交叉编译场景。

3.2 第一版：能跑就行的手工式 Makefile

先用最直接的方式写一版，目的是理清依赖关系：

score_app: main.o file_io.o stats.o gcc -o score_app main.o file_io.o stats.o main.o: main.c common.h file_io.h stats.h gcc -c -o main.o main.c file_io.o: file_io.c file_io.h common.h gcc -c -o file_io.o file_io.c stats.o: stats.c stats.h common.h gcc -c -o stats.o stats.c clean: rm -f *.o score_app

执行验证：

$ make gcc -c -o main.o main.c gcc -c -o file_io.o file_io.c gcc -c -o stats.o stats.c gcc -o score_app main.o file_io.o stats.o

再执行一次：

$ make make: 'score_app' 是最新的。

第二次什么也不做，说明增量编译已经生效。如果把 main.c 的修改时间戳动一下：

$ touch main.c $ make gcc -c -o main.o main.c gcc -o score_app main.o file_io.o stats.o

只有 main.o 被重编，其余 .o 直接复用。机制正确，但这个 Makefile 还远不算好用——扩展性差、没有变量、头文件依赖全靠手写、clean 目标没声明伪目标。

3.3 第二版：变量、模式规则和自动依赖生成

这一版我把它做成工程上常用的形态，每一步都能直接抄进自己的项目。

第一步，引入变量，把工具链、选项和文件列表收拢到一起：

CC := gcc CFLAGS := -Wall -Wextra -O2 -g CPPFLAGS := -I. LDFLAGS := TARGET := score_app SRCS := main.c file_io.c stats.c OBJS := $(SRCS:.c=.o) DEPS := $(OBJS:.o=.d)

解释几个关键点：

• CPPFLAGS := -I.：C 预处理器搜索头文件的路径，-I.表示当前目录。这里写 -I. 是为了让#include "common.h"等自定义头文件在多个目录结构时也能稳定找到，以后项目扩展了，往这里加路径就行。
• SRCS := main.c file_io.c stats.c：统一维护源文件列表，后续新增 .c 文件只需改这一行。
• OBJS := $(SRCS:.c=.o)：模式替换语法，把 SRCS 里的 .c 后缀替换成 .o。
• DEPS := $(OBJS:.o=.d)：后面自动依赖生成要用到的 .d 文件。

第二步，写主目标和链接规则：

all: $(TARGET) $(TARGET): $(OBJS) $(CC) $(LDFLAGS) -o $@ $^ .PHONY: all clean

all作为默认第一个目标，$@就是 $(TARGET)，$^是所有 .o 文件列表。这里我没写$(CFLAGS)，因为 CFLAGS 在编译阶段已经用掉了，链接阶段一般不需要。如果有些库需要链接，就加到 LDFLAGS 里。

第三步，用模式规则统一编译所有 .c 文件：

%.o: %.c $(CC) $(CPPFLAGS) $(CFLAGS) -c -o $@ $<

这一行替代了之前所有单独的 .o 规则。它的含义是：任何 .o 文件都由对应的 .c 文件编译而来。注意这里我没有列出头文件依赖，这是故意的，因为下一步要用编译器自动生成依赖。

第四步，自动生成头文件依赖：

%.d: %.c $(CC) $(CPPFLAGS) -MM -MF $@ -MT $(@:.d=.o) $<

这行的作用比较绕，我展开讲一下。gcc 的-MM选项可以输出一个 .c 文件所依赖的头文件列表，-MF指定输出到哪个文件，-MT指定生成规则的目标名。执行效果就相当于，对 main.c：

gcc -I. -MM -MF main.d -MT main.o main.c

会生成 main.d，内容类似：

main.o: main.c common.h file_io.h stats.h

这正好就是 make 判断 main.o 依赖哪些文件所需的规则。再用-include $(DEPS)把它导入 Makefile：

-include $(DEPS)

注意前面的减号-表示“如果文件不存在不要报错”。第一次构建时 .d 文件还不存在，Makefile 也能正常加载。而 .d 规则一旦存在，make 会自动维护这些派生文件。

有人可能会问：为什么要绕这么一圈？因为手写头文件依赖太容易漏了。你忘了写某个 .h，改头文件时 make 不会重编相关 .o，最后链接出一堆诡异的符号错误。用编译器自动生成依赖，这个坑从根本上被填平了。

第五步，加清理和安装目标。完整 Makefile 整理如下：

CC := gcc CFLAGS := -Wall -Wextra -O2 -g CPPFLAGS := -I. LDFLAGS := TARGET := score_app SRCS := main.c file_io.c stats.c OBJS := $(SRCS:.c=.o) DEPS := $(OBJS:.o=.d) all: $(TARGET) $(TARGET): $(OBJS) $(CC) $(LDFLAGS) -o $@ $^ %.o: %.c $(CC) $(CPPFLAGS) $(CFLAGS) -c -o $@ $< %.d: %.c $(CC) $(CPPFLAGS) -MM -MF $@ -MT $(@:.d=.o) $< -include $(DEPS) clean: rm -f *.o *.d $(TARGET) .PHONY: all clean

测试一下：

$ make gcc -I. -Wall -Wextra -O2 -g -c -o main.o main.c gcc -I. -Wall -Wextra -O2 -g -c -o file_io.o file_io.c gcc -I. -Wall -Wextra -O2 -g -c -o stats.o stats.c gcc -o score_app main.o file_io.o stats.o

看到 pattern 规则、自动依赖都在起作用了。改一个头文件验证：

$ touch common.h $ make gcc -I. -Wall -Wextra -O2 -g -c -o main.o main.c gcc -I. -Wall -Wextra -O2 -g -c -o file_io.o file_io.c gcc -I. -Wall -Wextra -O2 -g -c -o stats.o stats.c gcc -o score_app main.o file_io.o stats.o

所有包含 common.h 的 .c 文件全部重编，没包含 common.h 的模块则不参与。这个结果在手写依赖的时代要额外小心维护才能做到，现在是全自动的。

这就是从“手工小作坊”到“自动化工厂”的关键一步：你不再需要手动记账“谁依赖谁”，而是把记账这件事本身也自动化了。

3.4 进阶技巧：多目录、交叉编译和并行构建

工程继续变大之后，单目录的 Makefile 也不够用了。简单说几个我常用的扩展方向：

多目录结构。常见做法是在每个子目录放一个子 Makefile，顶层 Makefile 用$(MAKE) -C 子目录递归进入；或者把子目录里的源文件路径都写进 SRCS，然后在规则里用$(wildcard src/*.c)和$(notdir $(SRCS))这类函数处理路径。第一种更符合模块化习惯，第二种适合中小项目。多目录时头文件路径可能变成-Iinclude -Isrc/xxx，CPPFLAGS 要相应调整。

交叉编译。只需要修改变量即可，比如嵌入式环境：

CC := arm-linux-gnueabihf-gcc CFLAGS := -Wall -O2 -march=armv7-a CPPFLAGS := -I./include -I$(SYSROOT)/usr/include LDFLAGS := -L$(SYSROOT)/usr/lib

这就是为什么上一步要把工具链和参数变量化的原因——从 PC 平台切换到嵌入式平台，改动被限制在一个很小的区域，而不是把每条命令都翻出来改一遍。RV1106 这类带 NPU 的芯片平台还经常要追加--sysroot、特定的浮点 ABI 参数，全部用变量累积起来就行。

并行编译。make -j4或者make -j$(nproc)，能让多个互不依赖的编译任务同时跑，多核 CPU 的效率才能真正压榨出来。注意并行模式下的输出会交错，看起来稍微乱一点，但结果是正确的。

补充一个我常挂嘴边的建议：把 Makefile 看成代码来维护，加注释、分章节、保持可读性。很多项目坏就坏在 Makefile 写得跟天书一样，后面维护的人根本不敢动。

4. 高频报错与排查思路：这些坑我替你踩过了

4.1 “make: *** 没有指明目标并且找不到 makefile。停止。”

这是个见得非常多的报错，尤其是在刚拉下来的开源项目或新初始化的工作目录里。原因很简单：make 在当前目录下找不到名为 makefile 或 Makefile 的文件。排查顺序：

1. 先ls -a看看文件在不在。有些仓库把构建文件放在子目录，或者叫GNUmakefile、makefile.linux这些不同名字。
2. 如果文件名不是标准的那几个，用make -f 文件名显式指定。
3. 检查当前目录是否正确，是不是跑错了地方。
4. 如果文件在，但内容为空或开头格式有问题，make 也可能报“没有规则可创建目标”，这就要打开文件看内容了。

还有一种隐藏情况：你明明在项目根目录，却用make -C subdir想进子目录构建，结果 subdir 根本没有 Makefile。这时候系统提示的也是这个错误，注意-C的路径别拼错。

4.2 “missing separator” 与 TAB 陷阱

前面反复强调过，命令必须以 TAB 开头。这个报错出现时，九成是你的命令行用了空格。很多文本编辑器默认用空格代替 Tab，或者自动缩进设置坑人，于是你一粘贴代码就翻车。

我的处理办法：在 .vimrc 或编辑器配置里把 Makefile 类型的expandtab关掉，让 Tab 键老老实实输出 Tab 字符。粘贴网上的 Makefile 片段时，也先用cat -A Makefile看一眼行尾控制符，Tab 在输出里会显示成^I，一眼就能发现是不是被替换成空格了。

4.3 头文件改了却不重新编译

这是让无数人抓狂的“幽灵问题”：明明改了头文件里的宏定义，make 却像没看见一样，最后运行结果全错。根因基本就是依赖列表里没写头文件。

解决办法就是我上面演示的自动依赖生成方案，别手写依赖。如果你当前没有用 .d 机制，可以临时跑一句命令把所有 .o 删掉强制全量重编，但这不是长久之计。工程上务必把%.d: %.c规则和-include $(DEPS)加进去，一劳永逸。

另外一个容易忽略的坑是文件系统时间戳粒度问题。在有些文件系统或网络挂载目录下，文件修改时间不够新，make 判定“依赖不比目标新”，从而跳过重编。遇到这种诡异情况，先touch一下对应 .c 文件再 make，如果立刻能编了，说明是时间戳问题。频繁遇到就考虑调整文件系统挂载参数，或者接受“必要时手动 touch”的工作流。

4.4 头文件路径搜索顺序与 -I 的使用

如果你用的是普通 PC 上自带的头文件，比如<stdio.h>，make 自己就能找到。但自定义头文件在当前目录或者更深层目录时，编译会报fatal error: xxx.h: No such file or directory。

这时要理解 gcc 的头文件搜索顺序：

1. 双引号包含的头文件，先搜索当前 .c 文件所在目录。
2. 然后依次搜索-I指定的路径。
3. 再搜索系统默认路径（/usr/include 等）。

所以头文件在多层子目录时，在 CPPFLAGS 里写-I.、-Iinclude、-Isrc/common这些路径就行。注意不要写成过于绝对的长路径，尽量用相对于项目根目录的路径或者变量拼接，方便整个项目移动。

4.5 Makefile 与 CMake：工具选型的边界

用了 Makefile 一段时间后，你一定会遇到“神器 CMake”。好多文章把二者对立起来，其实它们更像不同粒度的工具：Makefile 是“构建规则引擎”，CMake 是“构建系统生成器”——CMake 通过 CMakeLists.txt 描述项目，然后生成 Makefile（或 Ninja 文件）再交给 make/ninja 执行。

什么时候该用什么？我的经验是这样的：

个人建议：个人项目、嵌入式 bootloader、内核模块这类场景，直接手写 Makefile 完全够用，而且你能清楚看到每一条命令在干什么。中大型跨平台项目、需要引入复杂第三方库的项目，优先用 CMake。两种都会是长期受用的技能，不存在“学了 CMake 就不用学 Makefile”这回事。实际上很多项目里 CMake 生成完 Makefile 后，还是要懂一点 make 的机制才能解决疑难问题。

4.6 关于 rv1106 等嵌入式平台的 Makefile 补充

最后补一块嵌入式相关的内容，因为热搜里出现了 rv1106。在瑞芯微这类芯片平台做 Linux 开发时，Makefile 的另一个重要作用是封装交叉编译工具链。你会经常看到这样一段：

CROSS_COMPILE ?= arm-rockchip830-linux-uclibcgnueabihf- CC := $(CROSS_COMPILE)gcc

然后把整个 SDK 的 sysroot 路径、库路径、头文件路径都落到变量里。这种写法能让我们在 PC 与开发板之间无缝切换构建目标。另外嵌入式开发里经常要“生成 makefile”或者修改-I头文件路径，其实都是在和 Makefile 打交道时的高频动作。理解了编译器搜索路径和依赖生成机制，这些操作就都顺理成章了。

收尾：一点个人经验

在我自己从“每条命令手打”到“写出一份顺手 Makefile”的转变过程中，最大的体会是：Makefile 不是为了炫技，也不是什么高深莫测的黑魔法，它只是把你每天重复的编译劳动固化下来，然后用机器的规则去执行。写 Makefile 最好的学习方法，就是把自己手头那个小项目拿出来，先把编译命令写清楚，再慢慢引入变量、模式规则、自动依赖，一步一步看着它从“手工小作坊”进化成“自动化工厂”。

最后分享两个小技巧：调试 Makefile 时可以用make -n，它会打印出将要执行的命令但实际不执行，非常适合检查规则写得对不对；想知道 make 内部维护了哪些变量和规则，用make -p可以把整个数据库打印出来。这两个命令在我排查问题的时候帮了无数次忙，希望也能帮到正在读这篇文章的你。