<p>最可靠方法是用宏组合：#define GCC_VERSION (GNUC 10000 + GNUC_MINOR 100 + GNUC_PATCHLEVEL)，再配合#ifdef GNUC_PATCHLEVEL防御性检查，避免误判Clang或旧版GCC。</p>
如何用预定义宏准确判断 GCC 版本
GCC 的 __GNUC__、__GNUC_MINOR__、__GNUC_PATCHLEVEL__ 是最可靠的版本标识，但容易误读成“主版本号即全部”——比如 __GNUC__ == 12 只表示主版本为 12，不区分 12.1、12.2 或 12.3.0。实际项目中必须三者组合解析。
- 直接拼接字符串不可靠：
std::to_string(__GNUC__) + "." + std::to_string(__GNUC_MINOR__)会漏掉 patch 级别，且无法表达如11.4.0这类完整格式 - 推荐用宏展开构造完整数字：定义
#define GCC_VERSION (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__)，这样GCC_VERSION对 12.2.1 就是120201，便于数值比较 - 注意：GCC 12+ 默认启用
-std=gnu++17后，__GNUC_PATCHLEVEL__才稳定可用；若用-std=c++11编译旧代码，某些补丁版本可能未定义该宏，需加#ifdef __GNUC_PATCHLEVEL__防御
Clang 版本宏与 GCC 兼容性陷阱
Clang 故意兼容 GCC 宏（__GNUC__ 等），但其真实版本由 __clang_major__、__clang_minor__、__clang_patchlevel__ 描述。混淆二者会导致误判——例如 Clang 15.0.7 在启用 -fms-extensions 时也会定义 __GNUC__ == 4，但它根本不是 GCC。
- 必须优先检测
__clang__宏是否存在，再决定用哪套宏：仅当!defined(__clang__) && defined(__GNUC__)才走 GCC 分支 - Clang 的
__clang_version__是字符串字面量（如"15.0.7"），不能直接用于预处理器条件判断，只能在运行时用constexpr解析或生成编译期字符串 - 跨平台构建时，CMake 中常用
if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang")辅助验证，避免纯宏判断失准
MSVC 的 _MSC_VER 如何映射到完整版本号
_MSC_VER 是整数，但微软从 VS2015 开始不再按“主版本×1000”简单映射。例如 VS2019 16.11 对应 _MSC_VER == 1929，VS2022 17.4 是 1934——中间没有线性关系，必须查表。
- 官方映射表藏在 MSVC 安装目录的
Tools/MSVC/*/bin/Hostx64/x64/cl.exe /?输出里，但更实用的是微软文档页 “Visual C++ compiler version”（搜索关键词即可） - 常见映射：
_MSC_VER == 1930→ VS2022 17.0，1933→ 17.3，1934→ 17.4；VS2019 最高到1929（16.11），再往上就是 VS2022 - 注意：
_MSC_FULL_VER包含补丁信息（如193431937表示 17.4.0），但末三位是内部构建号，非公开语义，不应依赖
跨编译器统一版本字符串生成方案
想在日志或编译警告中输出类似 "GCC 12.2.1" 或 "Clang 15.0.7" 这样的字符串，不能靠预处理器拼接，因为 C++ 标准禁止在 #define 中做字符串化操作（# 操作符不支持嵌套宏展开）。
立即学习“C++免费学习笔记（深入）”；
- 最简方案：用
constexpr函数在编译期生成字符串字面量，例如对 GCC：
constexpr auto get_gcc_version_str() {
return "GCC " + std::string_view{std::to_string(__GNUC__)} + "." +
std::string_view{std::to_string(__GNUC_MINOR__)} + "." +
std::string_view{std::to_string(__GNUC_PATCHLEVEL__)};
}std::to_string 在 constexpr 上下文中 C++20 才完全支持，C++17 需手动实现数字转字符串逻辑（如除10取余）GCC_VERSION），再用构建系统（CMake/Make）注入 -DVERSION_STR="GCC 12.2.1"，绕过预处理器限制真正难的不是识别，而是确保同一套宏逻辑在交叉编译（如 aarch64-linux-gnu-g++）、容器构建（Alpine 的 musl+clang）和 IDE 内置构建（VS Code C++ extension）中行为一致——这些环境可能屏蔽或伪造部分宏，得靠 static_assert 配合最小版本检查来兜底。
