clang不是gcc的升级替代，而是独立工具链；clang++编译c++17项目报undefined reference到std::string_view，因默认链接旧版libstdc++（不含该特性），须显式加-stdlib=libc++并安装libc++-dev。
Clang 和 GCC 本身不冲突，冲突来自你没明确告诉构建工具用哪个——默认情况下，make、cmake、甚至 g++ 脚本都可能继续调用 GCC，而你却以为自己在用 Clang。
为什么 clang++ 编译 C++17 项目会报 undefined reference 到 std::string_view
这不是 Clang 的 bug，而是它默认仍链接系统 libstdc++（GCC 的标准库），但老版本 libstdc++ 根本没实现 std::string_view 这类 C++17 特性。Clang 头文件和链接器没对齐，就炸了。
- 必须显式加
-stdlib=libc++：只有装了libc++-dev后，clang++ -stdlib=libc++ hello.cpp才能真正启用 LLVM 官方标准库 - 漏掉这个参数，
clang++就只是个“长得像 GCC 的前端”，ABI 和符号表全按 GCC 那套走，C++17/20 新特性直接不可用 - Ubuntu/Debian 上只装
clang不装libc++-dev，等于只装了半套；CentOS 7 上还得确认llvm-toolset-7是否带完整libc++
make 或 cmake 仍然调用 gcc/g++ 怎么办
别动 /usr/bin/gcc 的软链接——很多系统工具（比如 rpm-build、内核编译）强依赖原生 GCC，改它等于埋雷。
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
- 临时切换：运行
CC=clang CXX=clang++ make，环境变量只作用于当前命令 - CMake 项目：生成时指定
cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ..，比改全局 PATH 更安全 - 想永久生效？在项目根目录放一个
env.sh：export CC=clang; export CXX=clang++，每次source env.sh再构建
VSCode 里跳转失效、补全错乱
不是插件坏了，是微软的 cpptools 和 clangd 两个语言服务器同时在跑，互相抢控制权。
- 右下角看到
⚠️ C/C++ IntelliSense is disabled，基本就是冲突已发生 - 关掉其中一个：如果项目用 Clang 构建，就禁用
C/C++插件，只留clangd；反之亦然 - 真要共存？得手动配置
"C_Cpp.intelliSenseEngine": "disabled"并确保clangd的compile_commands.json路径正确——否则跳转还是指向 GCC 头文件
最常被忽略的点：Clang 不是 GCC 的替代品，它是另一套 ABI、另一套标准库、另一套诊断逻辑。混着用却不显式划清边界，问题一定出在链接阶段或构建配置里，而不是编译器本身。
