MSVC和GCC对C++标准的支持差异关键在于实现程度而非名义支持：语言特性、标准库组件及编译行为常滞后1–2个版本，需用__cplusplus和__cpp_lib_xxx宏实测验证。
怎么看MSVC和GCC对C++标准的支持差异
直接结论：不能只看“是否支持”，得看“支持到什么程度”——特别是核心语言特性、标准库组件、以及实际编译行为是否一致。很多代码在GCC下跑通，在MSVC里报错，不是因为语法写错了，而是同一标准下，两边实现进度差了1–2个大版本。
/std:c++xx 和 -std=c++xx 的启用效果不等价
MSVC的/std:c++17和GCC的-std=c++17名字相似，但背后约束力完全不同：
- MSVC的
/std:c++17默认**不强制更新__cplusplus宏值**，除非额外加/Zc:__cplusplus；GCC则直接设为201703L - MSVC在
/std:c++17下仍可能保留部分C++14行为（比如模板推导规则），而GCC在-std=c++17下更严格遵循标准语义 - MSVC 19.3x（VS 2022 17.5+）才真正把
/std:c++20设为“完整支持”，但GCC 13.1起才敢说-std=c++20可放心用concepts和ranges
标准库组件落地比语言特性更慢，尤其<filesystem>和<span>
语言关键字（如constexpr if）往往先被编译器解析，但标准库头文件是否可用、是否线程安全、是否需要链接额外库，才是跨编译器踩坑重灾区：
-
<filesystem>：GCC 8+ 默认可用（需-lstdc++fs），MSVC直到VS 2019 16.9才稳定支持，且必须配/std:c++17+_HAS_CXX17宏 -
<span>：GCC 10+、Clang 12+原生支持；MSVC 19.30（VS 2022 17.0）才开始实验性支持，19.34起才建议生产使用 -
<format>：GCC 13、Clang 15、MSVC 19.37（VS 2022 17.8）才同步完成，早于这些版本的任意一方都可能触发error C2039: 'format' is not a member of 'std'
验证当前编译器真实支持水平，别信文档，用代码测
靠查官网表格容易误判，尤其是CI环境或老旧IDE里嵌套的工具链。两行代码就能实测：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
#include <cassert> static_assert(__cplusplus >= 201703L, "C++17 not active");
再加一个运行时检查：
#ifdef __cpp_lib_filesystem #include <filesystem> #endif
关键点：
- 用
__cplusplus宏判断语言标准是否激活，不是看编译器版本号 - 用
__cpp_lib_xxx系列宏（如__cpp_lib_filesystem）确认标准库组件是否可用，而非头文件是否存在 - MSVC下记得加
/Zc:__cplusplus，否则__cplusplus永远是199711L或201402L，哪怕你写了/std:c++20
最常被忽略的是：同一个/std:c++20在VS 2022 17.3和17.8里，对std::generator的支持状态完全不同——前者根本没这个符号，后者才开始实验性提供。不测，光靠“VS 2022支持C++20”这种说法，项目上线前就可能卡住。
