C++没有统一宏能一键获取编译器详细版本号，需按编译器分别使用__clang__、_MSC_VER、__GNUC__等专属宏组合判断；__VERSION__格式不稳定，不可用于逻辑分支。
直接看结论：C++ 没有统一的宏能“一键获取编译器详细版本号”，但每个主流编译器都提供一组特定预定义宏，需组合判断；盲目依赖 __VERSION__ 或单个宏会漏掉关键信息（比如 MSVC 的 _MSC_VER 不含补丁号，Clang 的 __clang_major__ 等必须合用）。
怎么查 GCC/Clang 的完整版本（主+次+补丁）
GCC 和 Clang 都不直接暴露字符串形式的完整版本，但各自提供整数型宏，需手动拼接。注意：__VERSION__ 是字符串，但格式不稳定（GCC 可能带 build info，Clang 可能省略补丁号），不可用于逻辑分支。
- GCC 使用
__GNUC__、__GNUC_MINOR__、__GNUC_PATCHLEVEL__—— 三者必须同时检查，例如 GCC 12.3.0 对应__GNUC__ == 12 && __GNUC_MINOR__ == 3 && __GNUC_PATCHLEVEL__ == 0 - Clang 则用
__clang_major__、__clang_minor__、__clang_patchlevel__；但它可能伪装成 GCC（__GNUC__也定义），所以要先用__clang__宏排除 - 实际判断顺序建议：先
#ifdef __clang__，再#elif defined(__GNUC__) && !defined(__llvm__)（防 LLVM-GCC 误判）
MSVC 的版本宏为什么不能只看 _MSC_VER
_MSC_VER 是整数，表示主版本+次版本（如 1935 表示 VS 2022 17.5），但它完全不反映更新通道（Preview / GA / servicing release）和补丁号。仅靠它无法区分 17.5.0 和 17.5.10 —— 后者可能修复了关键模板解析 bug。
- 必须配合
_MSC_FULL_VER（含补丁号，如 193532215）和_MSC_BUILD（构建号，通常为 0，但某些内部版非零） - 注意：
_MSC_VER在较老 MSVC（如 14.0）中不包含补丁信息，_MSC_FULL_VER才是可靠来源 - 别用
_MSC_VER >= 1930做兼容判断——它会把 17.4.x 也包含进来，而 17.4.0 和 17.5.0 的 STL 行为可能不同
跨编译器判断时最容易踩的坑
不是所有宏在所有模式下都定义：启用 /Za（禁用扩展）会让 MSVC 不定义部分宏；Clang 的 -fms-extensions 可能让 _MSC_VER 出现，造成误判；GCC 的 -std=c++98 不影响宏，但某些旧版本 GCC 在 -std=gnu++xx 下才定义 __GNUC_PATCHLEVEL__。
立即学习“C++免费学习笔记（深入）”；
- 永远用
#ifdef+#elif链式判断，避免嵌套过深；推荐结构：#ifdef __clang__→#elif defined(_MSC_VER)→#elif defined(__GNUC__) - 不要假设宏“未定义 = 值为 0”——未定义的宏在
#if中被当作 0，但#ifdef才是安全检测方式 - 对齐行为差异比版本号更关键：比如 GCC 11+ 默认开启
-fconcepts，而 Clang 14+ 需显式传参；版本号相同不等于特性可用
真正麻烦的从来不是“怎么拿到数字”，而是“拿到之后怎么用”——比如某 patch 版本修复了 std::format 的 locale 处理，但它的宏值和上一个 patch 完全一样；这时候得查发行说明，而不是指望预处理器替你做决策。
