安全判断GCC版本应仅用__GNUC__、__GNUC_MINOR__、__GNUC_PATCHLEVEL__三宏做区间比较，如#if GNUC >= 12或#if GNUC > 11 || (__GNUC__ == 11 && GNUC_MINOR >= 3)，禁用硬匹配，且需结合特性宏（如__cpp_lib_format）验证具体功能支持。
直接用预定义宏做编译期判断，不是运行时查版本号——这是唯一可靠、零开销、构建可重现的方式。
怎么安全判断 GCC 版本
只依赖 __GNUC__、__GNUC_MINOR__、__GNUC_PATCHLEVEL 三个宏，它们在 GCC 和所有兼容 GCC 的工具链（MinGW、Clang 兼容模式）中都可用。硬匹配版本（比如 #if __GNUC__ == 12）极易出错，因为补丁更新可能引入行为变化，但主次版本语义稳定。
- 用
#if __GNUC__ >= 12表示支持 GCC 12.x 及以上（含 12.1、12.4） - 要精确到 11.3+，写成
#if __GNUC__ > 11 || (__GNUC__ == 11 && __GNUC_MINOR__ >= 3) - 别单独靠
__GNUC__判断 C++ 特性：GCC 10 和 11 对std::format支持程度不同，应结合__cpp_lib_format这类特性宏验证 - MinGW-w64 下这些宏照常有效，但注意其 STL 实现（如 libstdc++ 或 libc++）可能滞后于 GCC 官方版本
MSVC 版本只能用 _MSC_VER
_MSC_VER 是 MSVC 唯一跨版本稳定的宏，值为整数（VS2019=1920，VS2022=1930），clang-cl 也会定义它——这反而是好事，说明你处在 MSVC ABI 和头文件兼容环境中。
- 判断 VS2022+ 新增的
std::spanconstexpr 构造，用#if _MSC_VER >= 1930 - 绝对不要碰
_MSC_FULL_VER：它包含构建号（如 193933519），不同 Update 版本跳跃无规律，无法用于逻辑比较 -
WINVER或_WIN32_WINNT控制 Windows SDK 行为，和编译器版本无关，混用会导致头文件符号缺失或重定义 - 在 CMake 中，可通过
if(MSVC_VERSION GREATER_EQUAL 1930)做构建层控制，但源码内仍应以_MSC_VER为准
Clang 版本优先用 __clang_major__ 系列
Clang 自身提供 __clang_major__、__clang_minor__、__clang_patchlevel__，比依赖 __GNUC__ 更准确——尤其当你需要区分 Clang 15 的 [[no_unique_address]] 支持与否时。
立即学习“C++免费学习笔记（深入）”；
- 避免写
#ifdef __clang__就认为“是 Clang”：clang-cl 模式下也定义它，但实际走的是 MSVC 头文件路径和 ABI - 真要区分 native Clang 和 clang-cl，得组合判断：
#if defined(__clang__) && !defined(_MSC_VER) - 某些旧版 Clang（__clang_patchlevel__，需用
#ifdef __clang_patchlevel__包裹再比较 - Clang on Windows（非 clang-cl）会同时定义
__linux__吗？不会——它只按目标平台注入宏，Windows 目标下只定义_WIN32
跨平台宏组合时最易踩的坑
操作系统宏和编译器宏必须正交使用，不能混为一谈。新手常把 __GNUC__ 当作 Linux 标志，或以为 _MSC_VER 意味着 Windows 目标——其实它们完全独立。
-
_WIN32表示目标是 Windows，不管用 MSVC、GCC（MinGW）还是 Clang 编译 -
__linux__表示目标是 Linux，不管宿主机是 Windows（WSL）、macOS 还是真 Linux - Android 是特例：
__ANDROID__和__linux__同时定义，所以判断桌面 Linux 要写成#if defined(__linux__) && !defined(__ANDROID__) - macOS 上
__APPLE__必定存在，但若要用 Mach API 或 CoreFoundation，还得确认是否在 iOS 模拟器中：#ifdef TARGET_IPHONE_SIMULATOR需先#include <targetconditionals.h></targetconditionals.h>
真正难处理的永远不是“怎么写”，而是“宏在哪一级被定义”——CMake 的 target_compile_definitions、编译命令行的 -D、甚至第三方头文件的隐式定义，都可能覆盖或干扰你预期的宏状态。动手前先跑 g++ -dM -E /dev/null | grep -i linux 看一眼当前环境实际注入了什么，比猜半天靠谱得多。
