安全判断GCC版本需先排除Clang：#if defined(__GNUC__) && !defined(__clang__)，再用__GNUC__、__GNUC_MINOR__、__GNUC_PATCHLEVEL__三级宏做区间比较（如__GNUC__ > 12 || (__GNUC__ == 12 && GNUC_MINOR >= 2)），禁用字符串拼接和硬匹配，优先结合__cpp_*特性宏验证实际支持度。
没有“完整版本对照表全集”这种东西——C++ 标准不规定宏名、不强制编译器暴露版本细节，不同厂商（GCC / Clang / MSVC / ICC / EDG）各自定义宏，且同一编译器在不同版本中可能增删或调整宏值。所谓“对照表”，本质是经验性快查索引，不是标准契约。
怎么安全判断 GCC 版本（含 MinGW 和 Linux）
GCC 使用 __GNUC__、__GNUC_MINOR__、__GNUC_PATCHLEVEL__ 三级整数宏，但要注意：
-
__GNUC__只在 GCC 系列（含兼容模式）下定义，Clang 默认也定义它（为兼容），所以必须先排除 Clang：#if defined(__GNUC__) && !defined(__clang__) - MinGW-w64 的 GCC 9.0+ 开始支持
__GNUC_STDC_INLINE__，但旧版 MinGW 不一定可靠，别依赖它做分支逻辑 - 不要用字符串拼接方式构造版本号（如
"GCC " STRINGIFY(__GNUC__) "." STRINGIFY(__GNUC_MINOR__)...），预处理器不展开嵌套宏，得用两层宏技巧才能转成字符串
推荐写法：
#if defined(__GNUC__) && !defined(__clang__) # if __GNUC__ > 12 || (__GNUC__ == 12 && __GNUC_MINOR__ >= 2) # define MY_GCC_SUPPORTS_CONCEPTS 1 # endif #endif
Clang 版本识别为什么不能只看 __clang_major__
Clang 会模拟 GCC 宏（__GNUC__ 等），也会模拟 MSVC 宏（_MSC_VER），所以仅靠 __clang_major__ 无法区分“原生 Clang”和“Clang-cl 模式”（即 Clang 以 MSVC 兼容模式运行）。关键差异点：
立即学习“C++免费学习笔记（深入）”；
- Clang-cl 下
__clang__仍定义，但_MSC_VER也定义（值接近真实 MSVC），此时应优先信任_MSC_VER做 Windows ABI 判断 -
__apple_build_version__仅在 Apple Clang 中定义，普通 Clang（Linux/macOS Homebrew）不定义，不能用来判断是否为 Apple 工具链 - Clang 15+ 引入
__cpp_if_consteval，但 GCC 12 也支持，不能反推编译器——版本宏只适合做“能力兜底”，不适合做“身份断言”
MSVC 的 _MSC_VER 怎么换算成直观版本号
_MSC_VER 是整型，格式为 YYXX（非 YY.XX）：前两位是主版本年份，后两位是内部序号。常见映射：
-
_MSC_VER == 1930→ VS 2022 17.0（不是 19.30！） -
_MSC_VER == 1938→ VS 2022 17.8 -
_MSC_VER == 1940→ VS 2022 17.10（注意：1940 ≠ 19.40）
别硬记换算规则，直接查微软文档或用现成宏：
#if _MSC_VER >= 1930 // VS 2022+，可放心用 [[msvc::no_unique_address]] #endif
注意：_MSC_FULL_VER 包含补丁号（如 193832822），但只在命令行加 /Zc:__cplusplus 时稳定；未开启时可能截断，不可用于精确判断。
跨编译器检测 C++ 标准实际支持度，比查版本更可靠
版本号只是代理指标，真正要的是语言/库特性是否可用。优先使用标准特性宏：
-
__cpp_concepts >= 201907L比__GNUC__ >= 12更准确反映概念支持 -
__cpp_lib_format >= 202207L表示<format>大部分就绪，比查 Clang 15 还要细粒度 - MSVC 直到 19.35 才正确定义
__cpp_lib_ranges，但实际std::ranges::sort在 19.33 就能用——宏滞后于实现，需结合测试验证
结论：版本宏适合粗筛（比如禁用某编译器旧 Bug），但功能开关必须落到具体特性宏 + 最小可行编译测试。没有一张表能覆盖所有边缘情况，尤其是交叉工具链（如 Emscripten、ARM clang、Intel oneAPI）的定制宏。
