clang和gcc共存时应避免将多个编译器bin目录硬塞入path头部，而应通过别名（如alias gcc13='/opt/gcc-13/bin/gcc'）或临时修改path来切换；cmake需显式指定cmake_c_compiler等变量；clang链接libc++需先安装对应开发包，且编译器、标准库、链接器必须abi配套。
Clang和GCC共存时PATH怎么设才不冲突
直接往PATH头部硬塞多个编译器的bin目录，是最常见的翻车点——比如把/usr/local/clang-18/bin和/opt/gcc-13/bin都加进PATH，结果gcc和clang命令永远调用到第一个匹配的，根本没法按需切换。
正确做法是：只让系统默认路径（如/usr/bin）保留一个“兜底”版本，其余全部用显式路径或别名调用。
- 在
~/.zshrc里定义别名：alias gcc13='/opt/gcc-13/bin/gcc'、alias clang18='/usr/local/clang-18/bin/clang++' - 避免修改
PATH，除非你明确需要某版本成为当前shell会话的默认——这时用export PATH="/opt/gcc-13/bin:$PATH"，且记得unset PATH后能快速还原 - 别依赖
which gcc判断当前版本，改用gcc --version或readlink -f $(which gcc)看真实路径
CMake里怎么指定用Clang而不是GCC
CMake不会自动识别你装了几个编译器，它只认CMAKE_C_COMPILER和CMAKE_CXX_COMPILER这两个变量。不显式指定，它就去PATH里找第一个gcc或g++，大概率不是你想要的。
最稳妥的方式是每次cmake时传参：
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
cmake -DCMAKE_C_COMPILER=/usr/local/clang-18/bin/clang -DCMAKE_CXX_COMPILER=/usr/local/clang-18/bin/clang++ ..- 或者写个
toolchain.cmake文件，里面写死路径，再用cmake -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake .. - 切记：不要在
CMakeLists.txt里硬编码编译器路径，那会让项目失去可移植性
Clang链接libc++还是libstdc++？为什么-stdlib=libc++有时报错
Clang默认行为取决于系统：macOS上自动用libc++，Linux上多数发行版默认走libstdc++（因为没预装libc++）。但如果你手动指定-stdlib=libc++却提示cannot find -lc++，说明系统没装libc++开发包。
- Ubuntu/Debian：装
libc++-dev和libc++1 - CentOS/RHEL：装
libcxx-devel（EPEL源） - macOS：Xcode Command Line Tools自带，无需额外安装
- 如果项目依赖GCC生态的库（比如某些第三方静态库只提供
libstdc++ABI），强行切libc++会导致链接失败，这时就得保持-stdlib=libstdc++
多版本共存时最容易被忽略的ABI兼容问题
同一个项目用GCC 12编译、Clang 17链接，或者反过来，不是语法问题，而是ABI层面的灾难。比如std::string在libstdc++和libc++里的内存布局不同，跨库传递对象会崩溃。
关键原则只有一条：C++标准库实现、编译器、链接器三者必须配套。
- 用
gcc/g++，就配libstdc++，别碰-stdlib=libc++ - 用
clang/clang++，选libc++时确保所有依赖库也用libc++编译；选libstdc++时，确认Clang版本支持该libstdc++版本（比如Clang 16对libstdc++13支持不完整） - 头文件路径也要匹配：
clang++ -I/usr/include/c++/13配libstdc++13，-I/usr/include/llvm-cxx配libc++
