clang和clang++是LLVM工具链中同一可执行文件的两个入口，仅通过argv[0]名称区分行为：clang默认按C处理并链接libc，clang++默认按C++处理并自动链接对应标准库，混用易引发标准库不匹配、符号未定义或ABI冲突。
直接结论：用 clang++ 编译 C++ 源文件，用 clang 编译 C 源文件；混用或硬指定会触发隐式链接行为，容易导致标准库不匹配、符号未定义或 ABI 冲突。
clang 和 clang++ 本质是同一个程序的两个入口
它们不是两个独立编译器，而是 LLVM 工具链中同一个可执行文件（clang）的软链接或 wrapper。运行 clang --version 和 clang++ --version 输出完全一致；调用时仅靠 argv[0] 的名字决定行为模式。
关键差异在于：
- clang 默认把输入文件当 C 语言处理，链接 libc，不自动链接 C++ 标准库
- clang++ 默认把输入文件当 C++ 处理，自动添加 -stdlib=libc++（macOS）或 -stdlib=libstdc++（Linux），并链接 libstdc++ 或 libc++
- 即使你用
clang main.cpp，它也会尝试按 C++ 解析，但不会自动加-lstdc++—— 链接阶段大概率报undefined reference to 'operator new' - 反过来用
clang++ main.c也能过，但它会启用 C++ 模式解析 C 代码，可能因严格类型检查报错（比如隐式函数声明） - 二者都支持显式指定语言：
clang -x c++等价于clang++，clang++ -x c等价于clang
Linux 下 clang++ 默认链接 libstdc++，但行为不稳定
Clang 在不同 Linux 发行版上对 C++ 标准库的选择并不统一：Ubuntu/Debian 通常默认用 libstdc++，而某些 Alpine 或自建环境可能没装 libc++ 就 fallback 失败；更麻烦的是，clang++ 不会校验你系统里有没有对应版本的 libstdc++.so.6，只管传给链接器。
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
- 常见错误：
ld: cannot find -lstdc++—— 实际是系统没装libstdc++-dev包（Debian/Ubuntu）或libstdc++-devel（RHEL/CentOS） - 若想强制用
libc++，必须显式加-stdlib=libc++，且确保已安装libc++1-dev（Debian）或libcxx-devel（Fedora） - 用
clang++ -v main.cpp可看到完整链接命令，确认它实际调用了哪个库和链接器（ld还是lld）
跨平台项目必须显式控制 -stdlib 和链接器
macOS 上 clang++ 默认用 libc++，Linux 默认倾向 libstdc++，这会导致同一份 CMakeLists.txt 在两台机器上生成 ABI 不兼容的二进制 —— 尤其当你动态链接 stdlib 时，运行时报 symbol not found in flat namespace 或 GLIBCXX_3.4.29 not found。
- 可靠做法：所有 C++ 构建都加
-stdlib=libc++或-stdlib=libstdc++，不依赖默认 - 配套指定链接器：
-fuse-ld=lld（推荐）或-fuse-ld=gold，避免 GNUld对新 symbol 版本支持滞后 - 注意：CMake 中不能只写
set(CMAKE_CXX_STANDARD_LIBRARIES "-stdlib=libc++")，要通过target_compile_options+target_link_libraries分开控制编译与链接阶段
真正容易被忽略的点是：Clang 的 -stdlib= 只影响编译期头文件路径和链接期库选择，不改变运行时 ABI 兼容性判断。如果你混合使用 GCC 编译的对象和 Clang 链接的可执行文件，哪怕都用 libstdc++，仍可能因 __cxx11 符号修饰差异崩溃 —— 这类问题不会在编译或链接时报错，只在运行时暴露。
