必须显式指定 -std= 标准，Clang 不会自动推断或降级兼容；不指定时行为不可靠（如 Clang 14+ 默认 gnu++17），易致跨平台编译失败或隐式 ABI 不一致。
clang++ 编译时必须用 -std= 指定 C++ 标准，不指定则默认为较老的 C++98（Clang 14+ 默认是 -std=gnu++17，但行为不可靠）
Clang 不会自动推断你想要哪个 C++ 标准。即使代码里用了 std::optional 或 std::format，不加 -std= 就会报错——它不会“猜”，也不会降级兼容。
常见错误现象：
-
error: no template named 'optional'（用了 C++17 特性但没指定-std=c++17） -
error: 'std::format' is unavailable（C++20 功能，需显式启用） -
warning: 'auto' type specifier is a C++11 extension（Clang 提示你漏了标准）
正确做法：
- 用
-std=c++11、-std=c++14、-std=c++17、-std=c++20或-std=c++23—— 这些是严格遵循 ISO 标准的模式 - 避免用
-std=gnu++17等 GNU 扩展模式，除非你明确依赖 GNU 特有语法（如__attribute__扩展），否则容易在跨平台时出问题 - 项目中所有 C++ 文件应统一标准，混用会导致 ODR（One Definition Rule）违规或模板实例化失败
示例命令：
立即学习“C++免费学习笔记（深入）”；
clang++ -std=c++20 -o main main.cpp
为什么 -std=c++17 和 -std=gnu++17 不能混用
Clang 对 C++ 标准的实现分两层：ISO 标准层 + 扩展层。前者保证可移植，后者绑定特定编译器生态。
典型问题场景：
- 你在头文件里写了
[[maybe_unused]]（C++17 标准特性），但某处用了__attribute__((unused))（GNU 扩展），如果一个 TU 用-std=c++17，另一个用-std=gnu++17，链接时可能因符号修饰差异失败 - 某些 STL 实现（如 libc++）对扩展模式下的 ABI 处理更保守，导致
std::string_view在不同编译单元中大小不一致 - CMake 中若通过
set_property(TARGET tgt PROPERTY CXX_STANDARD 17)设置，它底层仍会生成-std=c++17，而非 GNU 模式——所以手动写命令时也应保持一致
macOS 上 clang++ 默认行为容易被忽略的细节
macOS 自带的 Clang（来自 Xcode Command Line Tools）在不同版本中默认标准不一致：
- Xcode 14（Clang 14）起，默认为
-std=gnu++17，但仅当未显式传入-std=时才生效 - 这个默认值**不作用于 CMake 项目**：CMake 会主动覆盖它，除非你禁用
CMAKE_CXX_STANDARD - 真正危险的是「没报错却行为异常」：比如
std::filesystem在-std=c++17下不可用，但在-std=gnu++17下可能被隐式启用（依赖 libc++ 版本），换到 Linux 就直接编译失败
建议始终显式声明，哪怕只是加个 -std=c++17 —— 它成本极低，却能堵住大量跨平台和升级隐患。
Clang 15+ 对 -std=c++23 的支持现状
Clang 15（2022 年发布）已支持大部分 C++23 核心特性，但仍有关键限制：
-
std::print尚未实现（libc++ 16+ 才开始提供），目前只能用std::format+std::cout -
std::expected在 Clang 16（2023）中才完整支持；Clang 15 需配合-fexperimental-library且不稳定 -
template<auto></auto>和if consteval在 Clang 15 已可用，但需确保 libc++ 版本 ≥ 15
如果你在 macOS 上用 Xcode 15+，libc++ 通常随 Xcode 升级，但不要假设系统自带的 /usr/include/c++/v1 是最新版——它往往滞后。真要用 C++23，推荐用 Homebrew 安装完整 LLVM 工具链并指定路径：
clang++-16 -std=c++23 -I$(brew --prefix llvm)/include/c++/v1 main.cpp -o main
