不能直接用__GNUC__/_MSC_VER获取完整语义化版本，因这些宏仅提供碎片化数字：GCC宏在非GCC编译器中无意义；_MSC_VER是十进制编码需查表换算且忽略补丁差异；__clang_version__为不可预处理的字符串；三者均无法可靠映射出如“12.3.4”结构。
没有标准的、跨编译器的“完整版本号宏”——__VERSION__ 是最接近的，但它格式不统一、不可解析，且不包含主次修订号结构；所有试图靠 __GNUC__、_MSC_VER、__clang_version__ 等宏拼出语义化版本（如 12.3.4）的行为，本质都是在做有损映射。
为什么不能直接用 __GNUC__ / _MSC_VER 获取完整版本？
这些宏只提供部分数字，缺失关键语义：
-
__GNUC__、__GNUC_MINOR__、__GNUC_PATCHLEVEL__只对 GCC 有效，Clang 和 ICC 定义它们但值无实际意义（Clang 常设为4、2、1以兼容旧代码） -
_MSC_VER是十进制编码：1935 表示 MSVC 19.35.x，需手动查表换算，且不区分预览版/补丁更新（如 19.35.32215 和 19.35.32216 都对应_MSC_VER == 1935） -
__clang_version__是字符串字面量（如"16.0.6 (https://github.com/llvm/llvm-project.git d78a7e9d225c...)"），无法在预处理器中拆解
实际项目中推荐的版本检测策略
按用途分层处理，不追求“一个宏打天下”：
- 功能可用性判断 → 用
__has_feature（Clang）、__has_builtin（Clang/GCC）、__has_include（C++17），比版本号更可靠 - 编译器特有语法兜底 → 检查
__clang__、__GNUC__、_MSC_VER等标识宏，再结合已知行为边界（例如：#if defined(_MSC_VER) && _MSC_VER >= 1930表示 VS2022 17.3+） - 构建系统级版本记录 → 在 CMake 或 Makefile 中读取
$CXX --version输出，写入生成头文件（如compiler_version.h），C++ 代码只读该头
常见编译器 _MSC_VER / __clang_major__ / __GNUC__ 对照速查
以下数值基于主流发布版本，仅用于条件编译中的**下界判断**（即“≥”而非“==”）：
立即学习“C++免费学习笔记（深入）”；
- MSVC：
_MSC_VER == 1930→ VS2022 17.0；1931→17.1；1932→17.2；1933→17.3；1934→17.4；1935→17.5；1936→17.6 - Clang：
__clang_major__ == 15→ Clang 15.0.x；16→16.0.x；17→17.0.x（注意：Clang for Windows 可能复用 MSVC STL，_MSC_VER仍有效） - GCC：
__GNUC__ == 11→ GCC 11.x；12→12.x；13→13.x；__GNUC_MINOR__和__GNUC_PATCHLEVEL__可进一步限定，但 GCC 本身不保证补丁级 ABI 兼容
最容易被忽略的陷阱：Clang on Windows 和 Intel LLVM
当 Clang 使用 MSVC 工具链（clang-cl）时，会同时定义 __clang__ 和 _MSC_VER，此时若只检查 _MSC_VER 会误判为原生 MSVC，导致启用错误的 intrinsics 或链接逻辑；同理，Intel LLVM 编译器（ICX）定义 __INTEL_LLVM_COMPILER，但也会定义 __clang__，且 __clang_major__ 值与真实 Clang 不同（如 ICX 2023.2 报告 __clang_major__ == 16，但行为更接近 Clang 15）。
必须优先检测排他性宏：#ifdef __INTEL_LLVM_COMPILER，再 #elif defined(__clang__) && !defined(_MSC_VER)，最后才是 #elif defined(_MSC_VER)。漏掉这一层，跨平台构建大概率在 CI 上突然失败。
