最稳方式是cmake命令行用-D指定编译器路径，如-DCMAKE_C_COMPILER=/opt/llvm/bin/clang -DCMAKE_CXX_COMPILER=/opt/llvm/bin/clang++，必须置于源码路径前且优先于环境变量和CMakeLists.txt中的set()。
直接在 CMake 配置阶段指定 clang 和 clang++ 路径即可生效，不需要改源码或重装工具链。关键在于指定时机和方式——晚于 project() 调用就无效，环境变量容易被覆盖，最稳的是命令行 -D 参数。
cmake 命令行用 -D 指定编译器（推荐）
这是最可靠、最透明的方式，尤其适合 CI/CD 或多版本共存环境。CMake 会优先采用 -D 设置的值，不依赖 PATH 或环境变量。
-
cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ..：走系统 PATH 查找，适用于已安装且在 PATH 中的 clang -
cmake -DCMAKE_C_COMPILER=/opt/llvm/bin/clang -DCMAKE_CXX_COMPILER=/opt/llvm/bin/clang++ ..：显式写死绝对路径，避免版本混淆（比如你本地同时有 clang-14、clang-17） - 如果 clang 是自建的（如从 LLVM 源码构建），必须用绝对路径——
set()在CMakeLists.txt中写相对路径或未导出的变量会失败 - 注意：该参数必须在
cmake命令末尾的源码路径（如..）之前，否则会被忽略
在 CMakeLists.txt 中用 set() 设置（仅限早期项目）
只在极少数场景下可用：项目完全由你控制、不对外发布、且所有开发者环境一致。因为一旦 project() 执行，CMake 就锁定编译器，再设就无效。
- 必须放在
cmake_minimum_required()之后、project()之前 - 写法示例：
set(CMAKE_C_COMPILER "/home/user/llvm-install/bin/clang") set(CMAKE_CXX_COMPILER "/home/user/llvm-install/bin/clang++")
- 不能只写
"clang"——这会让 CMake 再次去 PATH 查找，可能找到系统默认的旧版本 - 如果项目用了
find_package()或子模块，它们可能绕过你的设置，导致部分代码仍用 GCC 编译
用环境变量 CC/CXX（不推荐）
看似简单，但极易出问题：环境变量是全局的，会影响所有子构建、第三方库、甚至 CMake 自身的检测逻辑。
-
CC=clang CXX=clang++ cmake ..可能被某些find_program()调用覆盖 - Windows 上（尤其是 MSVC 环境）基本不可靠，
CXX可能被忽略，CMake 仍选cl.exe - 在 Docker 或容器化构建中，环境变量易被父镜像残留值污染
- 如果你真要用，务必加
message(STATUS "C compiler: ${CMAKE_C_COMPILER}")在CMakeLists.txt开头验证是否生效
Clang 特有选项和常见报错
Clang 和 GCC 的 flag 兼容性不错，但仍有几个典型差异点，不注意会导致构建失败或行为异常：
-
-std=gnu11在 Clang 下没问题，但-std=iso9899:1999这类 GCC 专用语法会报错，统一用-std=c99或-std=c11 - Clang 默认不开
-fPIC，做动态库时若没显式加，链接阶段会报relocation R_X86_64_32 against ... can not be used when making a shared object - 启用 LTO 时，必须确保整个工具链统一：用
clang编译 +lld链接（-fuse-ld=lld），混用ld.gold或系统ld会失败 - 嵌入式项目（如 Cortex-M）需额外指定
-target armv7m-none-eabi，且链接脚本里不能有 GCC 专属扩展（如PROVIDE的某些用法）
最容易被忽略的是：Clang 的 libc++ 和 libstdc++ 不兼容。如果你在 CMake 中写了 set(CMAKE_CXX_STANDARD_LIBRARIES "c++") 却没配好 libc++ 路径，链接时会找不到 std::string 符号——这时候得加 -stdlib=libc++ 并确保 libc++.so 在链接路径里。
