Clang 的 -M 参数单独使用无法生成可用依赖图，必须配合 -MG、-MP、-MT、-MF 才能输出规范的 .d 文件；否则依赖路径错乱、系统头混杂、目标名不匹配，导致后续绘图失败或构建异常。
Clang 的 -M 参数本身不生成图，只输出文本依赖列表；要得到可用的依赖关系图，必须配合 -MG、-MP、-MT、-MF 一起用，否则结果要么刷屏丢弃，要么路径错乱无法拼接。
为什么单独用 clang++ -M main.cpp 没用
它会把依赖直接打印到终端，且默认以源文件名（如 main.cpp:）为 target，和实际构建目标（如 obj/main.o）对不上；更糟的是，系统头（/usr/include/...）全混在里面，后续画图时节点爆炸、逻辑淹没。
-
-M只做一件事：扫描#include指令，生成形如main.o: main.cpp a.h b.h的行 —— 但前提是你要用-MT显式指定左边那个 target 名 - 不加
-MF deps/main.d，输出就飞走，没法存成文件供后续处理 - 不加
-MG，遇到自动生成的头（比如config.h还没生成）就报错中断，根本跑不完 - 不加
-MP，删掉某个头后make会因 missing rule 失败，不是你想要的“增量构建容错”
clang++ -M -MG -MP -MT "obj/main.o" -MF deps/main.d main.cpp 怎么写才不出错
这条命令是生成可落地依赖文件的最小可靠组合，每个参数都不可省略：
-
-MT "obj/main.o"必须带引号，且名字要和 Makefile 里最终生成的目标严格一致（比如你写$(OBJDIR)/main.o，这里就得写成"$(OBJDIR)/main.o"） -
-MF deps/main.d路径需提前mkdir -p deps，否则写入失败静默失败（Clang 不报错） -
-MG允许a.h不存在，但不会帮你生成它 —— 它只是让依赖生成流程不卡住，真缺头还得你补 - 如果项目有多个 .cpp，每个都要单独跑一遍，并确保所有
-MF输出到同一级目录（如全进deps/），否则后续合并时路径基准不统一
从 .d 文件到 Graphviz 图，清洗步骤不能跳
原始 .d 文件含绝对路径、重复项、系统头、空行和构建目标，直接喂给 dot 会出一张密不透风的废图。
- 先过滤系统头：
grep -v "/usr/include\|/usr/local/include" deps/*.d（具体路径用gcc -E -dM /dev/null | grep __VERSION__确认） - 抽关系并去重：
awk '{print $1, $3}' deps/*.d | sort -u（$1 是目标，$3 是第一个依赖，实际可能有多个，需循环处理） - 转相对路径：
sed 's|/full/path/to/project/||g'，注意结尾的/和全局替换标志g - 补 dot 语法：
echo "digraph {" > deps/graph.dot; sed 's/:/ ->/; s/ /\n/g' deps/cleaned.d >> deps/graph.dot; echo "}" >> deps/graph.dot
别拿 include-what-you-use 当 -M 用
include-what-you-use 输出的是“该删哪个头”“该加哪个头”，不是依赖边。它不递归展开间接包含（A.h → B.h → C.h，但 A.cpp 只 #include "A.h"），所以图里会断链。
- 它的 JSON 或文本输出没有 source→header 的明确映射，没法直接转成
"A.cpp" -> "C.h" - 真想结合用，只能先用
-M生成基础图，再用 iwyu 扫一遍，把标记为(should remove)的边人工过滤或标灰 - 误以为加了
-Xiwyu就自动产出图，结果发现满屏都是XXX.h should be removed，没有一条箭头
真正卡住人的从来不是命令敲不对，而是 .d 文件里那些没被清洗掉的绝对路径、重复引入、系统头混杂 —— 它们让图看起来“生成成功”，实则无法定位业务模块间的依赖流向。
