解压LLVM官方clang+llvm-*.tar.xz后即可直接使用，但需手动配置PATH和INCLUDE环境变量：PATH添加bin路径（如E:\llvm21\bin），INCLUDE添加lib\clang*\include及VS头文件路径，且路径不能含中文、空格或尾部反斜杠。
解压后直接可用，但PATH和INCLUDE必须手动补全
LLVM官方发布的 clang+llvm-*.tar.xz 压缩包是便携式二进制包，解压即得完整工具链（clang、lli、opt 等都在 bin/ 下），不需要传统意义上的“安装”。但 Windows 上仅把 bin 加入 PATH 远远不够——clang++ 会立即报 fatal error: 'stdio.h' file not found，因为头文件路径完全没被识别。
- 必须将解压目录的
bin子路径加入系统PATH环境变量（例如E:\llvm21\bin） - 必须额外设置
INCLUDE环境变量，值为：E:\llvm21\lib\clang\21.1.1\include（版本号需与实际解压包一致） - 若要编译链接 MSVC 标准库（最常见场景），还需在
INCLUDE中追加 Visual Studio 的头文件路径，例如：C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.39.33519\include - 路径中不能含中文、空格或特殊字符；
C:\Program Files\这类路径会导致下游工具（如clang-cl、lld、CMake 生成的 Ninja 脚本）解析失败
为什么 clang++ 找不到 windows.h 却不报错路径不存在
这不是路径写错了，而是 clang++ 默认不自动推导头文件位置。它只认 INCLUDE 环境变量（Windows 下）或 -I 参数指定的路径。即使你用管理员权限运行、PATH 正确、clang --version 能正常输出，只要 INCLUDE 缺失或顺序错乱，就会卡在标准头文件上。
-
clang++ -v test.cpp可查看实际搜索的 include 路径列表，确认lib\clang\*\include是否在其中 - 如果 VS 头文件路径也加了，但依然报错
unable to locate 'windows.h'，大概率是路径末尾多了反斜杠（\include\）或引号（"C:\...\include"），Windows 环境变量里不该带引号 - 多个 LLVM 版本共存时，
INCLUDE里不同版本的lib\clang\*\include不应同时存在，否则可能混用不兼容的内置宏定义
用 lli 运行 bitcode 时提示 “JIT compilation failed”
这通常不是 LLVM 本身的问题，而是运行时权限或环境缺失。Windows 上 lli 依赖 JIT 引擎动态生成机器码，UAC 或杀毒软件可能拦截写入临时页的操作。
- 确保命令行以普通用户身份运行（不要总用“以管理员身份运行”，反而触发更严策略）
- 检查是否禁用了 DEP（数据执行保护）：LLVM JIT 需要可执行内存页，某些企业策略会全局禁用
- 确认 bitcode 文件是用同版本
clang生成的（clang -c -emit-llvm test.c -o test.bc），跨版本可能因 IR 格式微变导致加载失败 - 如果只是想验证 IR 语法，优先用
llvm-as+llvm-dis，它们不触发 JIT，更稳定
PATH 和 INCLUDE 改完后命令行不生效？
Windows 环境变量修改后，已打开的命令行窗口不会自动刷新。这是最容易忽略的一环。
- 关闭所有已打开的 CMD / PowerShell / VS Code 终端，重新启动
- 在新终端中运行
echo %PATH%和echo %INCLUDE%确认值已更新 - VS Code 用户特别注意：必须重启整个 VS Code（不只是终端），否则 C/C++ 扩展的 IntelliSense 仍读取旧环境
- 若使用 Git Bash 或 WSL，它们不继承 Windows 的
INCLUDE，此时需在对应 shell 配置中手动导出export INCLUDE=...（但通常不推荐在 WSL 里混用 Windows LLVM）
cc -print-search-dirs 一眼看穿，也不像 macOS 那样有统一的 SDK 路径约定。每一步都得手动对齐，漏一个就卡住。 
