_WIN32是最可靠、通用的Windows平台判断宏，所有Windows工具链均预定义；_WIN64仅用于区分64位，不能单独标识Windows环境。
直接看宏定义，_WIN32 是最可靠、最通用的判断方式，Windows 下（无论 32/64 位、MSVC/Clang/MinGW）它一定被定义；_WIN64 仅在 64 位 Windows 下定义，不能单独用来判断是否为 Windows 环境。
为什么用 _WIN32 而不是 WIN32 或 WINDOWS
很多旧代码里会看到 #ifdef WIN32，但它不是标准定义——它是某些项目手动加的，编译器不保证提供。而 _WIN32 是 Microsoft Visual C++、Clang for Windows、MinGW-w64 等所有主流 Windows 工具链默认预定义的宏，属于事实标准。
常见错误现象：WIN32 在 MinGW 下未定义，导致条件编译失效；WINDOWS 几乎从不被任何编译器定义，纯属误传。
使用场景：写跨平台库时，需要在 Windows 下启用特定 API（如 CreateFileA）、禁用 POSIX 函数（如 fork），或调整路径分隔符逻辑。
-
_WIN32→ 所有 Windows 平台（x86/x64/ARM64）都定义 -
_WIN64→ 仅 x64/ARM64 Windows 定义，x86 Windows 不定义 -
__linux__→ GCC/Clang 在 Linux 下定义（注意双下划线） -
__APPLE__→ macOS 下定义，常与__MACH__同时存在
_WIN32 和 _WIN64 的关系与陷阱
_WIN64 是 _WIN32 的子集：只要定义了 _WIN64，就一定定义了 _WIN32；但反过来不成立。所以不能用 #ifdef _WIN64 来判断“是不是 Windows”，否则 x86 Windows 会被漏掉。
性能 / 兼容性影响：这两个宏只是编译期判断，无运行时开销。但若误用（比如把 _WIN64 当作平台标识），会导致 x86 Windows 构建失败或行为异常。
正确写法示例：
#ifdef _WIN32
// 所有 Windows 平台都走这里
#include
HANDLE h = CreateFileA(...);
#else
// 非 Windows：Linux/macOS/BSD
#include
int fd = open(...);
#endif
其他常见平台宏对照（避免混淆）
不同编译器对同一平台的宏命名可能不同，尤其在交叉编译或嵌入式场景中容易踩坑。例如：
- MinGW 和 MSVC 都定义
_WIN32，但 MinGW 不定义WIN32 - Clang on Windows 默认兼容 MSVC 宏，也定义
_WIN32 - macOS 下
__APPLE__必定定义，但__linux__绝对不定义（哪怕用 WSL 编译） - Linux 下
__linux__定义，但linux（无下划线）通常不定义
参数差异：这些宏都是编译器内置，无法通过 -D 手动覆盖（除非刻意取消，如 -U_WIN32，但不推荐）。
一个健壮的跨平台判断片段：
#if defined(_WIN32)
#define OS_WINDOWS 1
#define PATH_SEP '\\'
#elif defined(__linux__)
#define OS_LINUX 1
#define PATH_SEP '/'
#elif defined(__APPLE__)
#define OS_MACOS 1
#define PATH_SEP '/'
#else
#error "Unsupported platform"
#endif
实际项目中容易被忽略的细节
很多团队只测了 MSVC，忽略了 MinGW 或 Clang-cl 场景。例如：
- 某些头文件（如
winsock2.h）需在windows.h前包含，否则宏冲突 —— 这和平台判断无关，但常因条件编译位置不对引发 - CMake 中用
if(WIN32)判断主机系统，和源码中的_WIN32不是一回事（CMake 的WIN32指构建主机是 Windows，不是目标平台） - 交叉编译时（如用 Linux 编译 Windows 程序），源码仍要靠
_WIN32判断目标平台，而非构建机环境
最复杂的点往往不在“怎么写”，而在“什么时候写”：平台判断必须放在头文件包含之前，且不能依赖尚未定义的自定义宏。
