最可靠的方式是优先使用__LP64__和_WIN64宏判断，因它们在预处理阶段即确定、无运行时干扰：GCC/Clang在LP64系统（如Linux/macOS）定义__LP64__，MSVC在64位Windows下定义_WIN64；二者不重叠且覆盖主流平台，但MinGW等工具链需回退至sizeof(void*)==8作编译期兜底。
用 __LP64__ 和 _WIN64 判断 64 位系统最可靠
直接看宏定义比查 sizeof(void*) 更早、更确定——编译器在预处理阶段就决定了这些宏，不会受运行时环境干扰。GCC/Clang 在 LP64 模型（如 Linux/macOS）下定义 __LP64__；MSVC 在 64 位 Windows 下定义 _WIN64。两者不重叠，也不覆盖所有平台，但覆盖了主流场景。
-
__LP64__：Linux x86_64、macOS ARM64/x86_64 都有，但 Windows MinGW-w64 默认不定义（除非显式加-m64且启用 LP64） -
_WIN64：仅 MSVC 和兼容它的工具链（如 clang-cl）定义，MinGW 不定义 - 别用
__x86_64__或__aarch64__替代——它们判断的是 CPU 架构，不是“系统位数”；ARM32 上跑 64 位 kernel 时仍可能是 32 位用户态
Windows 下必须区分 MSVC 和 MinGW 工具链
同一个 Windows 系统，用 MSVC 编译时能用 _WIN64，换 MinGW 就失效。MinGW 默认走 ILP32 模型，即使目标是 x86_64，也只定义 __x86_64__，不定义 _WIN64。这时候得靠 sizeof(void*) == 8 回退，但必须确保它出现在编译期常量上下文中（比如 static_assert 或模板参数）。
- MSVC：
#ifdef _WIN64→ 64 位 Windows 用户态 - MinGW：
#ifdef __x86_64__仅表示目标架构，需配合__MINGW64_VERSION_MAJOR（如果可用）或直接测sizeof(void*) - 混用时容易漏掉 MinGW64 的 case，导致 64 位 Windows 下误判为 32 位
sizeof(void*) 是最通用的兜底方案，但有编译期限制
当宏不可靠或跨平台抽象层需要统一逻辑时，sizeof(void*) 是最终依据。但它不能用在预处理器条件里（#if sizeof(void*) == 8 会报错），只能用于 constexpr、static_assert 或模板特化。
- 可行：
static_assert(sizeof(void*) == 8, "64-bit expected"); - 不可行：
#if sizeof(void*) == 8→ 预处理器不认识sizeof - 模板中可写：
template<int sizeof> struct is_64bit;</int>，但不如宏直观 - 某些嵌入式平台（如 freestanding 环境）可能连
void*定义都不稳定，这时宏仍是唯一选择
别依赖 INTPTR_MAX 或 SIZE_MAX
这些是头文件里的常量，值由 stdint.h 或 cstdint 提供，但它们本身是编译结果，不是编译器内置宏。如果标准库头文件被裁剪、或用了非标准实现（比如某些 RTOS），INTPTR_MAX 可能未定义，或者值被硬编码成 32 位——它反映的是 ABI，不是编译器对当前平台的判断。
立即学习“C++免费学习笔记（深入）”；
-
#include <cstdint>后才能用INTPTR_MAX，而宏判断无需 include -
INTPTR_MAX == INT64_MAX在多数 64 位系统成立，但有些 32 位系统（如某些 DSP）也定义为INT64_MAX，只为支持大地址运算 - 它和
sizeof(void*)不一定同步：理论上可以有sizeof(void*) == 4但INTPTR_MAX == 0x7fffffffffffffff（极少见，但标准允许）
sizeof(void*)，最后才考虑 INTPTR_MAX。最容易被忽略的是 MinGW 和 MSVC 在 Windows 上的行为差异——同一套代码，在 Visual Studio 里走 _WIN64 分支，用 MinGW 编译却进了 32 位逻辑，连 warning 都没有。 
