最可靠的方法是结合平台专属宏与sizeof(void)验证：优先用_WIN64或__LP64__判断，再以sizeof(void)在编译期确认指针大小，避免单靠架构宏如__x86_64__误判x32等特殊ABI。
如何用预定义宏判断 C++ 编译目标是 32 位还是 64 位
直接看 __LP64__、_WIN64、__x86_64__ 这几个宏最可靠，但它们的生效条件和平台差异很大，不能只查一个。
-
__LP64__在 LP64 模型下为真（如 Linux/macOS 的 x86_64、aarch64），但 Windows 不用 LP64，所以__LP64__在 MSVC 下永远不定义 -
_WIN64是 MSVC 和 MinGW-w64 的可靠标志，只要目标是 64 位 Windows 就定义；但 Linux/macOS 完全不定义它 -
__x86_64__或__aarch64__表示 CPU 架构，不是 ABI —— 比如在 32 位内核上跑 32 位用户态（x32 ABI）时，__x86_64__仍可能被定义，但指针仍是 4 字节 - 真正反映指针大小的是
sizeof(void*)，但它不能在预处理期使用，所以宏判断只能作为编译期快速分流手段
跨平台可移植的判断写法（推荐）
把平台和 ABI 分开判断，避免单靠一个宏误判。下面这段逻辑覆盖 GCC/Clang/MSVC，且能区分 Windows x64、Linux x86_64、macOS arm64 等主流组合：
#if defined(_WIN64)
// Windows 64-bit (MSVC or MinGW-w64)
#define ARCH_BITS 64
#elif defined(__LP64__) || defined(__ILP32__)
// Unix-like LP64 or ILP32 (e.g. x86_64 Linux, aarch64 macOS)
#define ARCH_BITS 64
#elif defined(_M_X64) || defined(__x86_64__) || defined(__aarch64__)
// Fallback: arch hints — but verify with pointer size if critical
#if sizeof(void*) == 8
#define ARCH_BITS 64
#else
#define ARCH_BITS 32
#endif
#else
#define ARCH_BITS 32
#endif
注意：__ILP32__ 是少数环境（如 x32 ABI）才定义的，一般可省略；但保留它能让判断更严谨。
常见错误：把 __i686__ 当作 32 位标志
__i686__ 只表示编译器生成了 i686 指令集代码，和位宽完全无关 —— 它在 64 位系统上用 -m32 编译时才会出现，但此时仍是 32 位目标；而正常 x86_64 编译根本不会定义它。
立即学习“C++免费学习笔记（深入）”；
- 错：用
#ifdef __i686__推断是 32 位系统 → 实际只是指令集偏好 - 错：用
#ifdef __x86_64__直接当 64 位 → 在 x32 模式或某些交叉编译场景下会误判 - 对的做法：优先用平台专属宏（
_WIN64/__LP64__），再辅以sizeof(void*)验证关键分支
运行时动态确认指针大小（必要时）
预处理宏解决不了所有问题，比如同一份代码在不同 ABI 下编译，或者你正在写通用模板库。这时最稳妥的是在编译期常量表达式中用 sizeof(void*)：
static_assert(sizeof(void*) == 4 || sizeof(void*) == 8,
"Unsupported pointer size");
#if sizeof(void*) == 8
using size_type = uint64_t;
#else
using size_type = uint32_t;
#endif
这种写法在 C++11 起就完全合法，且被所有主流编译器优化为零开销。比依赖宏更贴近真实内存模型，尤其适合实现容器、序列化、FFI 接口等对二进制布局敏感的代码。
真正容易被忽略的是：宏只告诉你“编译器想让你认为是什么”，而 sizeof(void*) 才告诉你“它实际是什么”。两者不一致的情况虽少，但一旦发生（比如混用 ABI 的链接、旧版交叉工具链），排查起来非常隐蔽。
