Clang 和 LLVM 可执行文件必须在 PATH 中，否则会报 command not found；Windows 需将安装路径如 C:\Program Files\LLVM\bin 加入环境变量，Linux/macOS 需在 shell 配置文件中添加 export PATH="/opt/llvm-17.0.0/bin:$PATH" 并 source 生效，交叉编译或多版本共存时建议显式指定工具路径避免冲突。
Clang 和 LLVM 的可执行文件必须在 PATH 中才能被命令行或构建系统识别，否则会报 command not found 或 clang: command not found —— 这是路径没配对最直接的表现。
Windows 上 PATH 配置的关键位置
LLVM 安装包（如 llvm-16.0.0-win64.exe）默认把 bin 目录放在安装路径下，比如 C:\Program Files\LLVM\bin。这个路径必须加进系统级或用户级的 PATH 环境变量：
- 打开「系统属性 → 高级 → 环境变量」，在「系统变量」或「用户变量」中找到
Path，点击「编辑」→「新建」→ 粘贴完整路径（注意不要带尾部斜杠） - 如果安装时勾选了
Add LLVM to the system PATH for all users，这步可跳过，但需重启终端生效 - 验证方式：新开一个
cmd或PowerShell，运行clang --version和llvm-config --version，两者都应输出版本号 - 常见坑：路径含空格（如
Program Files）无需引号，但若手动编辑PATH时多加了分号、逗号或换行，会导致整个变量失效
Linux/macOS 下 PATH 的常见写法
不依赖包管理器（如 apt、brew）安装预编译二进制时，PATH 通常靠 shell 配置文件追加：
- 确认 LLVM 已解压到例如
/opt/llvm-17.0.0，其bin子目录包含clang、llc、llvm-config等 - 在
~/.bashrc或~/.zshrc末尾添加：export PATH="/opt/llvm-17.0.0/bin:$PATH" - 执行
source ~/.bashrc（或对应配置文件）后验证；which clang应返回该路径 - 注意：不要用
~符号写在export PATH中（如~/llvm/bin），shell 不会在export中展开它；必须写绝对路径
交叉编译场景下 PATH 的陷阱
当同时使用多个 LLVM 版本或混合 GNU 工具链时，PATH 顺序决定调用优先级：
-
make LLVM=1会尝试调用clang、ld.lld、llvm-ar等 —— 它们必须全部在PATH中，且版本一致 - 若
/usr/bin/clang（旧版）和/opt/llvm-17/bin/clang同时存在，而后者在PATH中靠后，make仍会调用旧版，导致ld.lld找不到或 ABI 不匹配 - 更稳妥的做法是显式指定工具路径：
make CC=/opt/llvm-17/bin/clang LD=/opt/llvm-17/bin/ld.lld LLVM=0，绕过PATH查找 - 对于树外构建（out-of-tree build），建议把
PATH设置为环境变量再运行make，避免子 shell 丢失上下文
VS Code / CMake 中的路径覆盖逻辑
IDE 或构建系统常绕过 PATH，直接读取配置项，此时环境变量只是兜底：
- VS Code 的
C/C++插件通过clang.executable设置指定clang路径，不看PATH - CMake 项目中，
CMAKE_C_COMPILER和CMAKE_CXX_COMPILER变量会覆盖PATH查找，例如设为/opt/llvm-17/bin/clang++ - Visual Studio 的 Clang 配置默认优先用内置副本（
clang-cl.exe），只有当CMAKE_CXX_COMPILER显式设为/path/to/clang++时才生效 - 容易忽略的是：CMake cache 一旦生成，修改
PATH或环境变量不会自动刷新，必须删除build/CMakeCache.txt或重新 configure
路径配置本身很简单，难的是多版本共存、IDE 缓存、构建缓存三者叠加后的隐性冲突。真正出问题时，别急着重装，先跑一遍 which clang、make -p | grep CC、cmake -L | grep COMPILER，把实际被调用的路径挖出来再说。
