clang -v 用于显示 clang 驱动器调用的完整工具链路径和参数，包括预处理器、编译器、汇编器、链接器各自的执行命令，但仅针对单个输入文件且不生成目标文件，不反映构建系统中实际执行的多文件编译命令。
clang -v 是看什么的，不是看编译命令的
clang -v 的核心作用是显示 clang 驱动器调用的完整工具链路径和参数，包括预处理器、编译器、汇编器、链接器各自的执行命令——但它**不等于编译时的详细命令输出**，也不会在构建过程中反复打印每行 gcc 或 clang++ 调用。它只运行一次，告诉你“如果我要编译这个文件，会怎么调用底层工具”。
常见误解是把它当 make V=1 用，结果发现没看到源文件对应的每一行编译命令。这是设计意图不同：-v 是诊断驱动行为，不是控制构建日志级别。
-
clang -v hello.c会列出所有阶段的完整命令（比如/usr/bin/clang -cc1 ...、/usr/bin/as ...），但只针对这一个输入文件，且不生成目标文件 - 它不会显示 CMake/Ninja 构建中实际跑的那几百条
clang++ -O2 -I... -c foo.cpp命令 - 如果你只想确认 include 路径或宏定义是否被正确传递，
clang -v -E -x c++ /dev/null 2>&1 | grep "^\s*#include"更直接
真正想看构建时每条编译命令，该用什么
你真正要的是构建系统执行时的实时命令流，不是 clang 驱动器的静态解析。这取决于你用什么构建后端：
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
- 用 Makefile（即
cmake -G "Unix Makefiles"）：执行make V=1，不是clang -v - 用 Ninja（即
cmake -G Ninja）：执行ninja -v，Ninja 不认V=1 - 想保存日志：加
2>&1 | tee build.log，比如ninja -v 2>&1 | tee build.log - VS Code 中 Ctrl+Shift+P → “Tasks: Run Task” → 选 build，再看终端输出，前提是 tasks.json 里 command 确实调用了
make或ninja
为什么 clang -v 有时看起来像编译命令，其实是假象
clang -v 输出里确实有类似 "/usr/bin/clang" "-cc1" "-triple" "x86_64-apple-darwin23.0.0" ... 这样的长行，但这只是驱动器模拟调用，并非真实执行。它甚至可能跳过某些阶段（比如不生成 .o 文件），或者因缺少输入而提前终止。
- 它默认不写任何输出文件，除非你显式加
-c或-o - 加
-c后它会真的编译并生成 .o，但只针对单个文件，无法反映多文件并行构建的真实顺序和参数差异 - 在 macOS 上，
/usr/bin/clang实际是 Apple Clang，版本绑定 Xcode 命令行工具；clang -v显示的 target 和 SDK 路径，和你在 CMakeLists.txt 里写的set(CMAKE_OSX_DEPLOYMENT_TARGET "13.0")是否一致，得靠它验证
容易忽略的兼容性细节
不同平台下 clang -v 行为略有差异，尤其涉及交叉编译或自定义 toolchain 时：
- Linux 上若装了多个 LLVM 版本（比如通过 apt 和 brew 混装），
which clang和clang -v显示的路径可能不一致，优先看后者输出的InstalledDir - RISC-V 交叉编译时，
clang -target riscv64gc -march=rv64gc -v hello.c才能显示 RISC-V 工具链路径，漏掉-target就还是本地 x86_64 工具链 - VS Code 的 C/C++ 扩展读取
c_cpp_properties.json时，不依赖clang -v，而是靠你填的includePath和compilerPath；填错路径会导致 IntelliSense 失效，但clang -v本身查不出来
真正影响构建结果的是构建系统实际执行的命令，不是 clang 驱动器的诊断输出。别让 -v 的“详细”二字误导你去它那儿找构建日志。
