必须成对设置CMAKE_C_COMPILER和CMAKE_CXX_COMPILER，否则因ABI不匹配导致链接失败或运行时崩溃；CMake在未显式设置前者时会从后者错误推导C编译器（如g++-11→gcc默认版），引发undefined reference、GLIBCXX版本错误或segmentation fault。
必须用绝对路径在命令行用 -D 显式指定，且 CMAKE_C_COMPILER 和 CMAKE_CXX_COMPILER 要成对设置，否则 ABI 不匹配、链接失败或运行时崩溃。
为什么不能只设 CMAKE_CXX_COMPILER？
CMake 在未显式设置 CMAKE_C_COMPILER 时，会从 CMAKE_CXX_COMPILER 推导出 C 编译器（比如把 /usr/bin/g++-11 自动换成 g++，再查 $PATH 找 gcc），结果往往是 g++-11 + gcc（默认版本），ABI 不一致。常见现象：
undefined reference to `std::__cxx11::basic_string...'- 链接阶段报
GLIBCXX_3.4.29 not found - 程序启动即
segmentation fault（尤其涉及std::string或std::list的跨库调用）
正确做法是两个变量都用完整路径成对指定：
cmake -S . -B build \ -D CMAKE_C_COMPILER=/usr/bin/gcc-11 \ -D CMAKE_CXX_COMPILER=/usr/bin/g++-11
CMakeLists.txt 里用 set() 设置是否可行？
可以，但有硬性限制：必须放在 project() 之前，且仅对首次配置生效；已有 build/ 目录时修改无效。
立即学习“C++免费学习笔记（深入）”；
典型错误写法：
project(MyApp) set(CMAKE_CXX_COMPILER "/usr/bin/clang++-15") <-- 太晚，已被忽略
正确位置：
cmake_minimum_required(VERSION 3.12) set(CMAKE_C_COMPILER "/usr/bin/clang-15") set(CMAKE_CXX_COMPILER "/usr/bin/clang++-15") project(MyApp)
注意：set() 中的路径仍是绝对路径；相对路径或仅写 clang++-15 会导致 CMake 回退到自动探测，失去控制。
工具链文件 vs 命令行 -D：哪个更推荐？
命令行 -D 更直接、更可复现，适合单项目或 CI 流水线；工具链文件（-D CMAKE_TOOLCHAIN_FILE=toolchain.cmake）适合多项目统一约束，但引入额外维护成本。
工具链文件内容示例（gcc11-toolchain.cmake）：
set(CMAKE_C_COMPILER "/usr/bin/gcc-11" CACHE FILEPATH "") set(CMAKE_CXX_COMPILER "/usr/bin/g++-11" CACHE FILEPATH "")
调用方式：
cmake -S . -B build -D CMAKE_TOOLCHAIN_FILE=./gcc11-toolchain.cmake
关键点：
- 必须加
CACHE FILEPATH ""，否则变量不进缓存，CMake 仍会覆盖 - 工具链文件无法绕过“首次配置才生效”规则 —— 已有
CMakeCache.txt时仍需清空build/
环境变量 CC/CXX 为什么不可靠？
它们只在全新构建目录下被读取一次，且极易被继承污染。例如：
你在 shell 中执行过 export CXX=clang++，之后所有子 shell 启动的 CMake（包括 IDE 内置构建、git hooks、子模块构建）都会悄悄使用 clang++，而你完全不知情。
更隐蔽的问题是：某些系统级脚本或容器镜像会预设 CXX，导致本地开发和 CI 行为不一致。实际项目中，这种“隐式依赖”比显式出错更难排查。
真正容易被忽略的是：哪怕你删了 build/，如果终端环境里还残留着 CC/CXX，CMake 依然会优先用它们 —— 而不是你 CMakeLists.txt 里写的 set()。
