安全判断GCC版本（含MinGW）应使用__GNUC__、__GNUC_MINOR__、__GNUC_PATCHLEVEL宏做区间比较，如#if __GNUC__ >= 12或#if __GNUC__ > 11 || (__GNUC__ == 11 && __GNUC_MINOR__ >= 3)，禁用硬匹配（如== 12）和不稳定宏。
直接看结论：用 _MSC_VER 判 MSVC、__GNUC__ 和 __GNUC_MINOR__ 判 GCC、__clang_major__ 等判 Clang，别碰 _MSC_FULL_VER 或硬匹配 __GNUC__ == 12 这类写法。
怎么安全判断 GCC 版本（含 MinGW）
GCC 系列编译器（包括 MinGW-GCC）提供三个整型宏：__GNUC__、__GNUC_MINOR__、__GNUC_PATCHLEVEL。它们是数值，可直接用于比较，但必须用区间逻辑：
- 写
#if __GNUC__ >= 12，不是#if __GNUC__ == 12—— 否则 12.1 会被漏掉 - 要精确到小版本（如 ≥ 11.3），得组合：
#if __GNUC__ > 11 || (__GNUC__ == 11 && __GNUC_MINOR__ >= 3) - 单独靠
__GNUC__不够：GCC 10 和 11 对std::format支持程度不同，建议叠加语言标准宏（如__cpp_lib_format >= 202207L）或特性宏验证 - MinGW 下这些宏行为一致，无需额外分支
怎么识别 MSVC 版本（含 clang-cl）
_MSC_VER 是唯一可靠指标，它对应 Visual Studio 主版本号（如 VS2022 17.3 → 1930），且 clang-cl 模式下也会定义它——这反而是好事，说明你正使用 MSVC 兼容的 ABI 和头文件环境：
- 用
#if _MSC_VER >= 1930判断是否支持 VS2022 新增的std::spanconstexpr 构造 - 绝对不要用
_MSC_FULL_VER：它含构建号（如 193030705），不同 Update 值跳跃无规律，无法做稳定条件编译 -
WINVER或_WIN32_WINNT控制 Windows SDK 行为，和编译器版本无关，混用会导致头文件行为错乱
Clang 版本检测优先用 __clang_major__ 系列
Clang 提供 __clang_major__、__clang_minor__、__clang_patchlevel__，语义与 GCC 宏一致，但注意：
立即学习“C++免费学习笔记（深入）”；
- 别依赖
__c（资料中截断，实际应为__clang__）：它只是个布尔宏，只表示“是 Clang”，不带版本信息 - Clang 在 Windows 上用 clang-cl 时，
_MSC_VER和__clang_major__同时存在，此时按需选择：用前者适配 MSVC 头文件行为，用后者控制 Clang 特有优化或警告 - 某些旧版 Clang（__clang_patchlevel__，保险起见只比对 major/minor
为什么不能混合用编译器宏和操作系统宏做版本推断
新手常犯的错误是看到 _WIN32 就以为是 MSVC，或看到 __linux__ 就默认 GCC。但现实更复杂：
-
_WIN32在 MinGW-GCC、clang-cl、MSVC 下都定义，但它只说明目标平台是 Windows，不说明编译器是谁 -
__linux__在 GCC、Clang（Linux host）、甚至某些交叉工具链下都定义，但 Clang on Windows（非 clang-cl）不会定义它 - Android NDK 的 Clang 会同时定义
__ANDROID__和__linux__，只靠__linux__会误判为桌面 Linux - 真正需要的是“编译器能力”而非“运行平台”，比如是否支持
[[likely]]，得查__has_cpp_attribute(likely)，而不是猜编译器版本
最易被忽略的一点：宏值在预处理阶段就固定了，但编译器实际行为还受命令行参数影响（如 -std=c++20 可能启用部分新特性，即使 __cplusplus 仍是 201703L）。所以版本宏只是起点，关键特性仍要搭配 __has_include、__has_cpp_attribute 或 __cpp_* 特性宏二次确认。
