最可靠方式是首次运行cmake时用-D参数强制指定：cmake -DCMAKE_C_COMPILER=/usr/bin/clang-15 -DCMAKE_CXX_COMPILER=/usr/bin/clang++-15 ..，两变量必须同时设置且用绝对路径，仅依赖PATH或CMakeLists.txt中set()易因缓存失效。
cmake 命令行指定 Clang 编译器最可靠
只靠 CC/CXX 环境变量或 set(CMAKE_CXX_COMPILER ...) 写在 CMakeLists.txt 里，经常失效——CMake 可能在 configure 阶段已缓存了系统默认编译器。必须在首次运行 cmake 时就用 -D 参数强制覆盖。
-
cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ..是最简方式，但依赖PATH，CI 中不稳定 - 生产环境推荐绝对路径：
cmake -DCMAKE_C_COMPILER=/usr/bin/clang-15 -DCMAKE_CXX_COMPILER=/usr/bin/clang++-15 .. - 两个变量必须同时指定：只设
CMAKE_CXX_COMPILER而漏掉CMAKE_C_COMPILER，C 文件仍可能被gcc编译，引发 ABI 不兼容 - 不能混用不同版本（如
clang-15+clang++-14），CMake 会报Compiler not found或静默降级
CMakeLists.txt 里 set() 方式仅限二次开发或固定环境
写在 CMakeLists.txt 中的 set(CMAKE_CXX_COMPILER ...) 仅在未通过命令行传入 -D 时才生效，且必须放在 project() 之前，否则被忽略。
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
- 路径必须是绝对路径，
clang这种裸名在 Docker 或 CI 中大概率找不到 - 不建议在共享项目中硬编码路径，会破坏其他人的本地构建流程
- 若真要写，加个存在性检查更稳妥：
find_program(CLANG_CXX_COMPILER NAMES clang++-15 clang++ PATHS /usr/bin /opt/llvm/bin)，再set(CMAKE_CXX_COMPILER ${CLANG_CXX_COMPILER})
Visual Studio 中改 Clang 需注意 clang-cl 模式
Windows 下 VS 的 Clang 支持默认走 clang-cl.exe，它模拟 MSVC 命令行接口、链接微软 STL，和原生 clang++ 行为不一致。
- 在“CMake 设置”里选 Clang 工具集后，实际设置的是
CMAKE_CXX_COMPILER=clang-cl.exe，不是clang++ - 若需标准 Clang 行为（比如用 libc++），得手动在“CMake 变量”里覆盖
CMAKE_CXX_COMPILER为完整路径，并加-stdlib=libc++到CMAKE_CXX_FLAGS -
clang-cl不支持某些 GNU 扩展语法（如__attribute__((packed))在结构体前），编译失败时先确认是否误入该模式
Clang 编译 CUDA 文件要骗过 CMake 的语言识别
CMake 默认不认识 .cu 后缀，也不会用 Clang 处理它——即使你指定了 Clang 编译器，.cu 文件仍可能被跳过或报 Unknown language。
- 必须显式告诉 CMake 把
.cu当 C++ 文件处理：set_source_files_properties(foo.cu PROPERTIES LANGUAGE CXX) - 确保 Clang 版本 ≥ 11 且编译时启用了 CUDA 支持（
clang --version输出含cuda） - 链接时可能需额外加
-lcudart，CMake 中用target_link_libraries(your_target PRIVATE cudart)
CMAKE_CXX_COMPILER 变量几乎没用；真正起效的只有重新删掉 build 目录，或用 cmake -U 清除缓存后再带 -D 重来。 
