4. 模式规则与静态模式：%通配符的使用、静态模式规则
说实话，刚开始写Makefile的时候，我特别烦那种重复劳动。一个项目里几十个.c文件，每个都要写一条编译规则？那还不如让我手敲gcc命令算了。后来我发现了模式规则和静态模式，这才算真正入了Makefile的门。
今天咱们就聊聊这两个东西——%通配符怎么用，静态模式规则是什么，以及在大项目里怎么靠它们减少重复代码。
4.1 %通配符：模式规则的灵魂
先看个最基础的例子。假设你有三个.c文件：main.c、utils.c、io.c。传统写法是这样的：
main.o: main.c
gcc -c main.c -o main.o
utils.o: utils.c
gcc -c utils.c -o utils.o
io.o: io.c
gcc -c io.c -o io.o
看着就累，对吧？用模式规则一句话搞定：
%.o: %.c
gcc -c $< -o $@
%在这里就是个通配符，它匹配文件名中相同位置的部分。比如main.o和main.c，%匹配的就是main。然后$<代表第一个依赖（也就是%.c），$@代表目标（也就是%.o）。
核心理解：模式规则的本质是「用通配符建立目标与依赖之间的对应关系」。你不需要关心具体文件名，Make会自动帮你匹配。
我个人习惯把模式规则放在Makefile靠前的位置，这样阅读起来一目了然。而且我建议你养成一个习惯——所有通用的编译规则都用模式规则写，别偷懒写具体的。
4.2 静态模式规则：更精准的控制
模式规则虽然好用，但它有个问题：它会对所有匹配的文件生效。有时候你只想对特定文件列表应用规则，这时候静态模式就派上用场了。
看个例子：
OBJS = main.o utils.o io.o
$(OBJS): %.o: %.c
gcc -c $< -o $@
语法结构是：目标列表 : 模式 : 依赖列表。说白了就是「我只对OBJS里列出的这些文件应用这条模式规则」。
我在项目中遇到过一个问题：项目里既有C文件又有C++文件，用普通模式规则的话，所有.o文件都会走同一条规则。但用静态模式，我可以这样写：
C_OBJS = main.o utils.o
CPP_OBJS = app.o module.o
$(C_OBJS): %.o: %.c
gcc -c $< -o $@
$(CPP_OBJS): %.o: %.cpp
g++ -c $< -o $@
这样C文件和C++文件各走各的规则，互不干扰。
小技巧：静态模式规则特别适合「同一个目录下混合多种语言」的场景。你想想看，如果不用静态模式，你是不是得写两套不同的模式规则？然后还得想办法让它们不冲突？静态模式直接帮你把范围限定死了。
4.3 在大型项目中如何用模式规则减少重复代码
大项目里，文件可能分布在几十个目录中。这时候模式规则的价值就真正体现出来了。
我参与过一个嵌入式项目，代码结构大概是这样的：
project/
├── src/
│ ├── main.c
│ ├── driver/
│ │ ├── uart.c
│ │ └── spi.c
│ └── protocol/
│ ├── tcp.c
│ └── udp.c
└── build/
如果每个目录都写一套规则，那Makefile得膨胀到几百行。但用模式规则，几行就搞定：
# 递归查找所有.c文件
SRCS = $(shell find src/ -name "*.c")
OBJS = $(SRCS:%.c=build/%.o)
# 模式规则：自动处理目录结构
build/%.o: %.c
@mkdir -p $(dir $@)
gcc -c $< -o $@
这里有个关键点：$(dir $@)会自动提取目标文件的目录路径，然后mkdir -p创建对应的目录结构。这样src/driver/uart.c编译出来的.o文件就会放在build/src/driver/uart.o里。
注意：我曾经犯过一个错误——直接用%.o: %.c处理跨目录的文件。结果Make报错说找不到依赖文件。为什么？因为%.o: %.c要求目标和依赖在同一个目录下。跨目录时必须把路径信息也写进模式里，就像上面build/%.o: %.c这样。
再进阶一点，你可以用模式规则处理不同编译选项：
# 调试版和发布版使用不同的模式规则
DEBUG_OBJS = $(SRCS:%.c=build/debug/%.o)
RELEASE_OBJS = $(SRCS:%.c=build/release/%.o)
build/debug/%.o: %.c
@mkdir -p $(dir $@)
gcc -g -O0 -c $< -o $@
build/release/%.o: %.c
@mkdir -p $(dir $@)
gcc -O2 -c $< -o $@
这样你只需要维护两条模式规则，就能同时支持调试和发布两种编译配置。如果不用模式规则，每个文件都得写两遍，那画面太美我不敢看。
4.4 模式规则与静态模式的对比
| 特性 | 模式规则 | 静态模式规则 |
|---|---|---|
| 适用范围 | 所有匹配的文件 | 指定的文件列表 |
| 语法 | %.o: %.c |
$(OBJS): %.o: %.c |
| 灵活性 | 高，自动匹配 | 更高，可精确控制 |
| 适用场景 | 单一语言、统一编译选项 | 多语言、不同编译选项 |
嗯，这里要注意一点：静态模式规则并不是模式规则的替代品，它们是互补的。我个人的经验是：
- 如果项目里所有文件都用同一套编译规则，用模式规则就够了
- 如果不同文件需要不同的规则，用静态模式规则
- 如果项目特别大，建议两者结合使用
4.5 知识体系总览
下面这张图总结了模式规则和静态模式的核心逻辑，以及它们在大项目中的应用方式：
从这张图可以看出来，模式规则和静态模式规则是Makefile自动化的两大支柱。模式规则解决「怎么写通用规则」的问题，静态模式解决「怎么精确控制规则应用范围」的问题。两者结合，就能应对从几十个文件的小项目到几千个文件的大项目。
我的建议：刚开始用Makefile的时候，先掌握模式规则就够了。等遇到「不同文件需要不同编译选项」的场景，再引入静态模式。别一开始就把事情搞复杂了。
好了，关于模式规则和静态模式就聊这么多。记住一句话：能用模式规则解决的问题，就别手写具体规则。这是减少Makefile重复代码最有效的方法。