Clang 和 GCC 可安全共存，关键在于调用时避免混用：默认互不干扰，但通用命令如 g++ 或 c++ 会优先使用 PATH 中首个；需通过 which 和 --version 确认实际调用路径与版本，CMake 等工具可能因 update-alternatives 隐式切换编译器，应显式指定 CMAKE_CXX_COMPILER；Clang 默认链接 libstdc++，改用 libc++ 需额外安装对应库。
Clang 和 GCC 可以安全共存，关键不是“能不能装”，而是“调用时会不会混用”——默认情况下它们互不干扰，但一旦你用 c++ 或 g++ 这类通用命令，系统就只认 PATH 里排最前的那个。
怎么确认当前默认编译器是哪个
别猜，直接查：
- 运行
which g++和which clang++，看路径是否指向不同位置（比如/usr/bin/g++vs/usr/bin/clang++） - 运行
g++ --version和clang++ --version，确认输出版本号无误 - 注意：
gcc和g++是 GNU 工具链的入口，clang和clang++是 LLVM 的入口，名字不重叠，天然隔离
为什么 cmake 有时会偷偷用错编译器
CMake 默认找 cc / c++ 命令，而很多发行版（尤其 Ubuntu）会用 update-alternatives 把 c++ 指向某个具体实现，比如 g++-12 或 clang++-16。你没动过它，但它可能已被系统或别人配置过。
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
- 检查：
ls -l $(which c++)，如果看到指向/etc/alternatives/c++，说明启用了update-alternatives - 临时指定编译器：CMake 命令行加
-DCMAKE_CXX_COMPILER=clang++或-DCMAKE_CXX_COMPILER=/usr/bin/clang++-16 - 永久方案：在
CMakeLists.txt开头加set(CMAKE_CXX_COMPILER clang++)（仅限项目级，不推荐全局使用）
Clang 链接 libc++ 还是 libstdc++？
这是共存时最容易出错的点：Clang 默认在 Linux 上链接 libstdc++（GCC 的标准库），但如果你显式写了 -stdlib=libc++，就必须确保系统装了 libc++1 和 libc++1-dev（Ubuntu/Debian）或对应包；否则编译通过、链接失败，报一堆 undefined reference to 'std::__1::...。
- 查当前链接行为：
clang++ -v main.cpp 2>&1 | grep "selected"，看末尾选的是libstdc++.so还是libc++.so - 强制用 libstdc++（兼容性更好）：
clang++ -stdlib=libstdc++ main.cpp - 强制用 libc++（更现代，但需额外安装）：
clang++ -stdlib=libc++ main.cpp -lc++abi - 注意：GCC 不能用
-stdlib=libc++，会直接报错；Clang 用-stdlib=libstdc++则依赖 GCC 安装的libstdc++版本，不是所有版本都兼容 C++17/20
真正麻烦的从来不是装多个编译器，而是构建脚本或 IDE 里隐式依赖了某个默认行为——比如 CMake 不设编译器、Makefile 硬写 g++、VS Code 的 c_cpp_properties.json 里 compilerPath 指向旧版本。共存的前提是“明确控制”，而不是“假装它们能自动协商”。
