可靠入口是__GNUC__、_MSC_VER、__clang_major__三宏，须用区间比较（如>=12）而非硬匹配==，禁用运行时查版本、字符串解析及_MSC_FULL_VER等不稳定宏。
直接看结论：编译器版本号不能“查”，只能“判”——用预定义宏做编译期区间判断，__GNUC__、_MSC_VER、__clang_major__ 这三个才是可靠入口；硬匹配 ==、拼字符串、调运行时 API 全部无效且危险。
怎么安全判断 GCC 版本（含 MinGW）
GCC 系列（包括 MinGW-GCC）提供三个整型宏：__GNUC__、__GNUC_MINOR__、__GNUC_PATCHLEVEL__，它们是编译器内置常量，可直接用于数值比较。
- 写
#if __GNUC__ >= 12，不是#if __GNUC__ == 12—— 否则12.1和12.4都会被跳过 - 要精确到小版本（如 ≥ 11.3），必须组合：
#if __GNUC__ > 11 || (__GNUC__ == 11 && __GNUC_MINOR__ >= 3) - 单独靠
__GNUC__判断 C++ 特性极不可靠：GCC 10 支持std::format但不完整，GCC 11 才基本可用，应叠加__cpp_lib_format >= 202207L验证 -
__GNUG__是冗余宏，值与__GNUC__完全一致，无需引入
怎么识别 MSVC 版本（含 clang-cl）
_MSC_VER 是唯一稳定、跨 VS 版本可比的宏，值对应主版本号（VS2019=1920，VS2022=1930，VS2025=1940），且 clang-cl 模式下也定义它——这不是 bug，而是明确告诉你 ABI 和头文件行为已对齐 MSVC。
- 用
#ifdef _MSC_VER判断是否处于 MSVC 兼容环境，#if defined(_MSC_VER) && _MSC_VER >= 1930是语法错误（预处理器不支持&&） - 绝对不要用
_MSC_FULL_VER：它含构建号（如193030705），不同 Update 值跳跃无规律，无法用于逻辑比较 -
WINVER或_WIN32_WINNT控制 Windows SDK 行为，和编译器版本无关，混用会导致头文件符号缺失或重定义 - CMake 中可用
if(MSVC_VERSION GREATER_EQUAL 1930)做构建层控制，但源码内仍必须以_MSC_VER为准
怎么区分原生 Clang 和 clang-cl
__clang__ 是 Clang 的可靠标识，但它在 clang-cl 模式下依然定义——此时 _MSC_VER 也同时存在。关键在于分支优先级：先判 _MSC_VER，再判 __clang__，最后才轮到 __GNUC__。
立即学习“C++免费学习笔记（深入）”；
- 原生 Clang（macOS/Linux/Xcode）：
#if defined(__clang__) && !defined(_MSC_VER) - clang-cl（Windows + MSVC 工具链）：
#ifdef _MSC_VER分支优先处理，ABI/STL/头文件路径全部按 MSVC 规则走 - Clang 版本判断必须用
__clang_major__系列，而非模仿 GCC 的__GNUC__值——语义完全不同，比如__clang_major__ >= 15才表示支持[[no_unique_address]] - 旧版 Clang 可能未定义
__clang_patchlevel__，保险起见只比对major和minor，并用#ifdef __clang_patchlevel__包裹
为什么不能混合用编译器宏和操作系统宏推断版本
新手常误以为 _WIN32 意味着 MSVC，或 __linux__ 就等于 GCC。现实是：
-
_WIN32在 MinGW-GCC、clang-cl、MSVC 下都定义，它只说明目标平台是 Windows，不说明编译器是谁 -
__linux__在 GCC、Clang（Linux host）、甚至某些交叉工具链中都会定义，但它和编译器厂商完全正交 -
__cplusplus只表示标准版本（如201703L），不是编译器身份标识；g++和clang++都会定义它 - 用
sizeof('a') == 1或空结构体大小来“猜”编译器？属于未定义行为依赖，不同版本可能突变，绝对不要用
最易忽略的一点：clang-cl 下 _MSC_VER 和 __clang__ 同时存在，这不是冲突，而是设计使然——它意味着你正在使用 Clang，但目标 ABI、头文件、链接规则都对齐 MSVC。此时必须优先响应 _MSC_VER，而不是强行塞进 Clang 分支。
