必须显式指定CMAKE_C_COMPILER且置于project()前，推荐命令行方式：cmake -S . -B build -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++；工具链文件更利于协作，需设CMAKE_C_STANDARD防Clang默认C90报错。
Clang 编译 C 语言时，CMake 必须显式指定 C 编译器且不能依赖环境变量或默认行为；漏掉 CMAKE_C_COMPILER 或把它写在 project() 之后，CMake 仍会调 GCC。
怎么让 CMake 真正用 clang 而不是 GCC
命令行方式最可靠，且优先级高于 CMakeLists.txt 中的 set()：
-
cmake -S . -B build -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++—— 这是唯一能绕过 PATH 查找、强制覆盖默认行为的方式 - 如果只编译 C（无 C++），仍需同时传
-DCMAKE_CXX_COMPILER=clang++，否则 CMake 可能因检测失败而回退到 GCC -
set(CMAKE_C_COMPILER clang)写在project()之前才生效；写在之后会被忽略，且不会报错 - Windows 上用
clang-cl时，必须额外加-T ClangCL，否则生成目标可能不兼容 MSVC CRT
CMakeLists.txt 里哪些地方容易写错
常见错误不是“没写”，而是“位置错”或“类型冲突”：
-
project()必须在set(CMAKE_C_COMPILER ...)之后、且在任何add_executable()或add_library()之前 - 若项目含 C 和 C++ 混合源码，
set(CMAKE_CXX_STANDARD 17)不影响 C 文件，但set(CMAKE_C_STANDARD 11)必须显式设置，否则 Clang 默认用 C90，可能触发for loop initial declarations are not supported - 不要用
if(CMAKE_COMPILER_IS_GNUCC)判断 Clang：Clang 也匹配该条件；改用if(CMAKE_C_COMPILER_ID MATCHES "Clang") - 避免在
set()中硬编码路径如/usr/bin/clang，应依赖 PATH 或用工具链文件统一管理
验证 Clang 是否真的被用了
光看 cmake .. 输出 “-- The C compiler identification is Clang” 不够，得看实际构建行为：
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
立即学习“C语言免费学习笔记（深入）”；
- 进
build/目录，执行make VERBOSE=1 | grep -E "(clang|gcc)"，确认命令行中出现clang -c而非gcc -c - 检查
CMakeCache.txt，搜索CMAKE_C_COMPILER:行，值必须是完整路径或可执行名（如clang），不能是空或gcc - 编译失败时若报
error: unknown argument: '-frecord-gcc-switches'，说明 GCC 特有 flag 被传给了 Clang，根源常是第三方 FindXXX.cmake 或旧版 CMakePresets 配置残留
工具链文件比 set() 更适合团队协作
把编译器选择从 CMakeLists.txt 剥离出来，能避免污染项目逻辑，也方便 CI 切换：
- 新建
toolchain-clang.cmake，内容只需三行：set(CMAKE_C_COMPILER clang)set(CMAKE_CXX_COMPILER clang++)set(CMAKE_SYSTEM_NAME Generic) - 调用时：
cmake -DCMAKE_TOOLCHAIN_FILE=toolchain-clang.cmake -S . -B build - CI 中可直接替换 toolchain 文件路径，无需改源码；本地开发也能共用同一套配置
- 注意：工具链文件中不能用
project()或find_package()，它只负责工具定义
最常被忽略的是：Clang 对 C 标准版本更严格，CMAKE_C_STANDARD 不设或设错会导致语法错误；而 CMake 默认不校验 C 编译器是否真支持该标准，直到编译才暴露。
