嘿，我来帮你拆解下这个问题！从你描述的现象来看，最常见的原因是Make的变量展开机制或者规则定义方式踩了坑，以下是几个最可能的细节，你可以对照自己的Makefile排查：

1. 循环生成target时没正确处理变量延迟展开 #

这是最容易犯的错误！如果你用foreach+eval来批量生成bootload_前缀的target，没转义变量的话，所有生成的target都会复用循环最后一次的变量值，看起来就像被“覆盖”了。

举个错误的例子：

CS_TARGETS = cs00 cs01 cs02

# 坑就在这里：eval里的$(cs)是延迟展开，循环结束后cs的值是最后一个元素cs02
$(foreach cs, $(CS_TARGETS), $(eval bootload_$(cs): ; echo Bootloading $(cs)))

执行make bootload_cs00时，输出的会是Bootloading cs02——因为Make会等到执行规则时才去求值$(cs)，这时候循环已经跑完了，cs的最后值是cs02。

正确的写法是用$$转义变量，让eval里的变量即时展开：

CS_TARGETS = cs00 cs01 cs02

# 用$$(cs)转义，确保每个target绑定对应的cs值
$(foreach cs, $(CS_TARGETS), $(eval bootload_$(cs): ; echo Bootloading $$(cs)))

# 或者更优雅的方式：用模式规则替代循环，根本不会有展开问题
bootload_%:
	@echo Bootloading $*

2. 重复定义了同一个target规则 #

如果你的Makefile里，某个bootload_xxx target被定义了两次——比如先写了一个针对bootload_cs00的专属规则，后来又通过批量生成的方式重新定义了它——那么后面的规则会直接覆盖前面的，这也会让你觉得“原有target被覆盖”。

比如：

# 原有针对cs00的专属规则
bootload_cs00:
	@echo 原有逻辑：烧录cs00

# 后面批量生成的规则覆盖了前面的
CS_TARGETS = cs00 cs01
$(foreach cs, $(CS_TARGETS), $(eval bootload_$(cs): ; echo 新逻辑：烧录$(cs)))

执行make bootload_cs00时，只会执行后面的“新逻辑”规则。

3. 递归展开变量导致的意外 #

如果你用=（递归展开）来定义存放target列表的变量，而不是:=（简单展开），后续修改原始列表会让target列表意外变化，也可能出现类似“覆盖”的错觉。

比如：

CS_LIST = cs00
# 用=的话，bootload_targets会在每次引用时重新计算
bootload_targets = $(addprefix bootload_, $(CS_LIST))
# 后面追加元素
CS_LIST += cs01

这时候bootload_targets会包含bootload_cs00 bootload_cs01，而如果你的规则是基于bootload_targets定义的，可能会和你最初的预期不符。换成:=就能避免这个问题，因为它会即时展开变量值，后续修改CS_LIST不会影响已经定义的bootload_targets。

排查小技巧 #

你可以用make -n bootload_cs00命令，让Make只打印要执行的命令而不实际运行，这样就能清楚看到到底是哪个规则被触发了，快速定位是哪个部分出了问题。

内容的提问来源于stack exchange，提问作者benathon