最可靠的方法是组合判断__WIN64、__LP64__等宏：Windows用__WIN64，Unix-like用__LP64__，32位环境用__WIN32/__i386__/__arm__，因sizeof(void*)在预处理器中不可用，且单宏易误判架构与ABI差异。
怎么用预处理器宏判断是32位还是64位编译环境
直接看 __LP64__、_WIN64、__x86_64__ 这几个宏最可靠，但它们的适用范围不同，不能只查一个。
常见错误是只依赖 sizeof(void*) == 8 或运行时判断——这在编译期就失效了；还有人误以为 __i686__ 表示64位（其实它是32位x86的标识）。
-
__LP64__：GCC/Clang 在 LP64 模型下定义（即 long 和 pointer 为64位），Linux/macOS 64位默认启用，Windows 不启用（Windows 用 LLP64） -
_WIN64：MSVC 和 MinGW-w64 在64位 Windows 编译时定义，Windows 专属，32位 Windows 下未定义 -
__x86_64__或__aarch64__：表示目标 CPU 架构，不是 ABI 模型；__x86_64__存在 ≠ 一定是64位程序（极少数交叉编译场景可能误导，但日常可信赖）
跨平台可移植的判断写法
要同时兼容 Windows、Linux、macOS，且区分清楚“指针位宽”而非“CPU架构”，推荐组合判断：
#if defined(_WIN64)
// Windows 64-bit (LLP64)
#elif defined(__LP64__)
// Unix-like 64-bit (LP64)
#elif defined(_WIN32) || defined(__i386__) || defined(__arm__)
// 32-bit: Windows x86, Linux x86, ARM32 等
#else
// 兜底：比如 __aarch64__ 单独存在但没进上面分支？需按需补充
#endif
注意：_WIN32 在 64位 Windows 的 MSVC/MinGW 下**依然定义**（因为它是 Windows API 兼容标识），所以不能用来判64位，只能辅助判32位环境。
立即学习“C++免费学习笔记（深入）”；
Windows 桌面自动化技能，支持鼠标控制（移动/点击/拖拽/滚轮/截图）、键盘输入（文字输入/按键/组合键）、窗口管理（查找/聚焦/最大化/最小化/关闭/移动）、截图并发送文件。提供两种截图方式：Python pyautogui 截图（集成在自动化流程中）和 PowerShell + .NET 零依赖截图（支持区域截图和多显示器）。当用户需要自动化 Windows 桌面操作、控制鼠标键盘、管理窗口、执行 GUI 自动化任务、截图发送文件时使用。
为什么不能只靠 sizeof(void*)
这个表达式在预处理器阶段不可用，所有 #if 分支里不能出现 sizeof；它属于运行时或编译时常量表达式，只能用于 static_assert 或模板特化，无法控制宏分支逻辑。
- 想在头文件里条件包含不同 ABI 的结构体定义？必须用宏，不能用
sizeof - 某些库（如 FFmpeg、Boost）内部用宏隔离内存对齐策略，也是同样原因
- 误用会导致预处理器跳过本该启用的代码块，编译失败或行为异常
容易被忽略的交叉编译和嵌入式场景
在用 aarch64-linux-gnu-g++ 编译 ARM64 程序时，__aarch64__ 有定义，但 __LP64__ 也有；而用 arm-linux-gnueabihf-g++ 编译 ARM32，则三者都无定义。这时候如果只检查 _WIN64，会漏掉所有非 Windows 平台。
更隐蔽的是 Android NDK：Clang 编译 aarch64 目标时定义 __LP64__，但编译 armeabi-v7a 时既不定义 __LP64__ 也不定义 _WIN32，得靠 __arm__ + !__aarch64__ 组合识别。
真正可靠的判断永远依赖「目标平台规范」+「工具链实际行为」，而不是记忆某个宏的名字。
