GCC能过但MSVC报错，大概率是误用了GCC/Clang扩展或依赖其宽松模板解析；应检查__attribute__、__builtin_*等非标语法，统一用宏封装平台差异，并在CMake中启用/permissive-和严格标准模式。
GCC能过但MSVC报错，大概率不是代码写错了，而是你无意中用了GCC/Clang的扩展特性，或者依赖了它们更宽松的模板解析行为。MSVC（尤其旧版本）对标准合规性更敏感，但现代MSVC（VS2019+ /std:c++17及以上）其实已大幅收敛差异——问题往往出在“没显式约束”和“没封装差异”上。
怎么判断是不是编译器扩展惹的祸
先看错误是否指向特定语法：比如 __attribute__、typeof、__builtin_expect、GCC风格的变参宏逗号省略（LOG("x") 后面没参数）、或 __PRETTY_FUNCTION__ 这类非标宏。这些在MSVC里直接未定义或语法不识别。
- 用
__attribute__((visibility("default")))做导出？MSVC要用__declspec(dllexport)，必须用宏封装 - 写了
__builtin_clz(x)？MSVC得换成_BitScanForward或std::countl_zero（C++20） - 头文件里用了
#include <bits></bits>？MSVC根本不认这个非标头 - 函数参数用了
[[gnu::always_inline]]？MSVC忽略gnu::前缀，应改用[[likely]]或纯inline
模板和 constexpr 在GCC与MSVC间最常翻车
MSVC默认延迟模板实例化，GCC更早检查；同一个模板代码，GCC可能在定义处就报错，MSVC拖到调用才崩。constexpr 函数如果含未定义行为（比如越界访问、未初始化变量读取），GCC可能静默放过，MSVC直接拒绝编译。
- 所有模板声明后加
extern template显式实例化（若已知使用类型），可减少MSVC链接时符号冲突 - 避免在 constexpr 函数里调用非 constexpr 成员函数，哪怕它“看起来能算”——MSVC校验更严
- 友元声明务必写全限定名：
friend class std::hash<mytype>;</mytype>而不是friend class hash;，否则GCC可能通、MSVC报错 - 用
if constexpr替代 SFINAE，C++17起三者都支持，且语义清晰无歧义
统一函数签名宏：3行解决 __PRETTY_FUNCTION__ 和 __FUNCSIG__ 不兼容
日志、断言、调试器里要打印当前函数名时，硬写 __PRETTY_FUNCTION__ 或 __FUNCSIG__ 会导致跨平台编译失败。标准 __FUNCTION__ 又太简陋（只有函数名，无参数/返回值）。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
直接在公共头里加这三行：
#if defined(_MSC_VER) # define FUNC_INFO __FUNCSIG__ #elif defined(__GNUC__) || defined(__clang__) # define FUNC_INFO __PRETTY_FUNCTION__ #else # define FUNC_INFO __FUNCTION__ #endif
之后所有地方统一用 FUNC_INFO，既保留签名信息，又避开编译器特有宏直写。
- 注意：不要在宏里拼接字符串字面量（如
"in " __FUNCTION__），MSVC对这种操作支持不稳定 - 如果只需要函数名（不含模板参数），用
__func__最稳妥，C99起全平台支持 - 某些场景下
FUNC_INFO展开后过长（尤其带嵌套模板），影响日志可读性，可额外加一层截断逻辑
CMake里必须做的三件事才能真正统一行为
光改代码不够，构建配置不一致，等于白搭。CMakeLists.txt 里这几项不能省：
- 强制语言标准：
set(CMAKE_CXX_STANDARD 17)+set(CMAKE_CXX_STANDARD_REQUIRED ON) - 开启严格模式：GCC/Clang 加
-Wall -Wextra -pedantic，MSVC 加/W4 /permissive-（后者强制标准兼容模式） - 统一宏定义：
add_compile_definitions(_CRT_SECURE_NO_WARNINGS)（Windows平台常见）或add_compile_definitions(NOMINMAX)防止min/max宏污染
最容易被忽略的是 /permissive-：它让MSVC放弃部分历史兼容行为，主动对齐ISO标准——很多“GCC能过MSVC挂”的问题，开它就解决了。但要注意，它可能暴露原有代码里隐藏的非标用法，得一并修掉。
