答案是目标文件错误依赖其所在目录导致时间戳频繁变更。Makefile中若将build/、deps/等目录直接列为依赖项，每次写入文件都会更新目录时间戳，触发目标反复重建；应改用order-only依赖（如| build/）并用-MT指定目标名，避免依赖链污染。
Makefile 里 .dep 文件反复生成，根本停不下来
这不是 VSCode 的问题，是 Makefile 自身的依赖关系写错了。典型表现是每次 make 都重新生成 main.dep、foo.dep，甚至触发无限递归调用——背后几乎都是「目标文件依赖了它自己的目录」。
比如这样写就危险：
main.o: main.cpp main.h build/ \t$(CC) -c $< -o $@
build/ 是个目录，每次往里面写 .o 或 .dep，目录时间戳就变；而 main.o 又依赖这个目录，导致每次都认为需要重做。
- 检查所有规则中是否把目录（如
build/、obj/）直接列为依赖项 - 改用显式文件依赖，比如
main.o: main.cpp main.h | build/（|表示 order-only dependency，目录存在即可，不因时间戳触发重建） - 生成
.dep文件时，用-MT指定目标名，避免它错误地把自身目录也写进依赖列表
foo.o 和 main.o 轮流被删重建，编译永远“不干净”
这其实是上一个问题的连锁反应：当 foo.o 因依赖目录变动被重建，它的修改时间就比 main.o 新；而 main.o 规则又依赖 foo.o（比如链接阶段或隐式依赖），下一轮 make 就判定 main.o 过期；接着 main.o 更新，又轮到 foo.o……形成交替震荡。
立即学习“C++免费学习笔记（深入）”；
关键不是哪个文件先动，而是依赖图里出现了环状或时间敏感的隐式路径依赖。
- 运行
make -d抓日志，搜is newer than和remaking，定位哪两个目标在互相触发 - 禁用自动依赖生成（注释掉
-MMD -MP相关逻辑），先用手工写的.d文件验证逻辑是否闭环 - 确保所有中间目录（
build/、deps/）只用mkdir -p创建，不参与任何目标的时间戳比较
VSCode Ctrl+Shift+B 卡住不动，其实是在等 make 自己死循环
VSCode 不会干预 make 的执行逻辑，它只是起一个进程。如果你在终端里手动跑 make 也卡住、CPU 占满，那问题一定出在 Makefile 本身，不是配置没配对。
但 VSCode 会让这个问题更难察觉：它默认不显示 make -d 级别的调试输出，你只看到“正在构建…”一直转圈。
- 先在 VSCode 集成终端里手动执行
make -j1（禁用并行），观察是否卡在某个目标 - 在
tasks.json的"args"里加上["-j1", "--debug=b"]，让输出带依赖分析信息 - 别依赖
Makefile Tools插件的自动配置——它可能静默加了-f或覆盖了MAKEFLAGS，干扰原始行为
为什么改了 Makefile，VSCode 还是旧行为？
因为 make 默认只检查目标文件和依赖的时间戳，不检查 Makefile 本身是否改动。如果你改了规则但没删掉已生成的 .o 或 .dep，旧的依赖关系还在生效。
尤其当 .dep 文件里记录了过期的路径或错误的依赖链，make 就会照着错的走，完全无视你刚修好的 Makefile。
- 每次大改 Makefile 后，手动清掉
build/、obj/、deps/目录再试 - 在 Makefile 里加一条
clean-deps:规则，专门删*.d和*.dep - 不要用
include *.d加载依赖文件，除非你确认每个.d都由对应源文件生成且路径绝对可靠
