clang++ -m 是提取头文件依赖最可靠方式，仅反映实际 #include 路径，不受宏干扰；需配合 -mg、-mp、-mt 和 -mf 正确使用，避免路径混乱与输出丢失。
用 clang++ -M 提取头文件依赖列表最可靠
直接生成可读、可处理的依赖关系文本，比解析编译器内部行为或硬啃 #include 逻辑更稳。它不依赖预处理器展开后的结果，也不受宏定义干扰，只反映实际被 #include 指令拉进来的头文件路径。
常见错误是误用 -MM（忽略系统头）却忘了加 -MF 指定输出文件，导致依赖信息直接刷屏而无法收集；或者在多文件项目里对每个 .cpp 单独跑，却没统一路径前缀，后续拼图失败。
-
clang++ -M -MG -MP -MT "obj/main.o" -MF deps/main.d main.cpp：生成main.d，内容形如obj/main.o: main.cpp helper.h /usr/include/c++/11/string -
-MG允许缺失头文件（比如自动生成的头），避免因找不到而中断 -
-MP为每个依赖项生成空目标，防止 Make 在头文件删除后报错 - 务必用
-MT显式指定目标名，否则默认用源文件名，和构建系统对不上
把 .d 文件转成 Graphviz .dot 图需要清洗路径
原始 .d 输出含绝对路径、系统头、重复项和构建目标，直接喂给 dot 会得到一张密密麻麻、无法聚焦业务逻辑的图。关键不是“能不能画”，而是“画出来有没有用”。
典型翻车点：用 sed 简单删 /usr/ 前缀，结果把项目里带 /usr 的子模块也干掉了；或者没去重，同一个头被不同 cpp 引入十次，图里就出现十个孤立节点。
- 先用
gcc -E -dM /dev/null | grep __VERSION__确认系统头位置，再用grep -v过滤掉匹配的行 - 用
awk '{print $1, $3}'抽出 “目标: 依赖” 关系，再用sort -u去重 - 所有路径统一转为相对项目根目录，例如
sed 's|/full/path/to/project/||' - 最后按
dot语法补上digraph { ... }和边定义，比如"main.cpp" -> "helper.h"
include-what-you-use 能指出冗余 #include，但不生成图
它本质是个静态分析补丁版 Clang，专注诊断“哪些头根本没被用到”，适合清理代码，不是依赖可视化工具。强行拿它的 JSON 输出去画图，会漏掉间接依赖（比如 A.h 包含 B.h，B.h 包含 C.h，但 A.cpp 只显式写了 #include "A.h"），图就断了。
容易踩的坑是把它和 clang++ -M 混用：以为开了 -Xiwyu 就自动产出依赖边，结果发现输出里只有“应该删这个头”“应该加那个头”，没有边数据。
- 它输出格式是文本块，每行以
(<code>xxx.h) 或should add these lines:开头，没法直接映射为图节点 - 若真想结合使用，只能把它当“校验层”：先用
-M生成图，再用iwyu扫一遍，把标记为冗余的边人工标灰或删掉 - 不支持 Windows 路径分隔符
\，在 MSVC 工具链下需先转义或改用 WSL
用 compile_commands.json 驱动依赖提取时注意命令完整性
CMake 生成的 compile_commands.json 是权威编译命令来源，但它记录的是最终传给编译器的完整命令行——可能含 -I、-D、-isystem，甚至 -x c++。漏掉任何一项，clang++ -M 就可能找不到头或误判系统头。
常见错误是直接取 command 字段字符串然后 sed 替换 g++ 为 clang++ -M，结果宏定义丢失、头搜索路径错乱，依赖列表残缺不全。
- 必须保留全部
-I、-isystem、-D参数，且顺序不能乱（-I优先级高于-isystem） - 用 Python 或
jq解析 JSON，拼出新命令：clang++ -M -MG -MP [所有原参数] source.cpp - 对每个
file字段对应的源文件单独执行，别试图一次性喂多个文件——-M不支持 - 输出的
.d文件名建议按源文件名哈希生成，避免并发写入冲突
真正难的从来不是“怎么画出一张图”，而是让图里的每个箭头都对应一次真实的、可复现的头文件拉取行为。路径是否标准化、系统头是否过滤干净、间接依赖是否保全——这些细节一旦松动，图就从工具变成幻觉。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
