编译期宏如_M_X64、__aarch64__仅反映目标架构而非运行时CPU，须用getauxval（Linux）、__cpuid（Windows）或sysctlbyname（macOS）做运行时指令集检测。
编译期判断：_M_X64、__aarch64__ 等宏只反映目标架构，不反映运行时实际 CPU
这些宏由编译器在预处理阶段定义，完全取决于你用什么命令编译，和程序最终跑在哪台机器上无关。比如用 clang++ -target aarch64-linux-gnu 编译出的二进制，即使拷到 x86_64 机器上运行（通过模拟器），__aarch64__ 依然为真——但它根本不是原生运行。
常见误判点：
- 把
__x86_64__当作“当前 CPU 是 x86_64”的证据，结果在 Apple Silicon 上通过 Rosetta 2 运行该程序时仍命中，实际执行的是翻译层 - 在交叉编译环境（如构建 ARM 固件）中依赖
__ARM_ARCH_7A__做逻辑分支，却没意识到它对运行时检测毫无意义 - 混淆
_M_AMD64（MSVC）和__x86_64__（GCC/Clang）：二者语义一致，但不能混用；MSVC 下__x86_64__未定义
运行时检测：__builtin_cpu_is 不可用，必须靠 __cpuid 或 getauxval
Clang 和 GCC 都不提供类似 __builtin_cpu_is("aarch64") 的运行时架构识别函数。所谓“CPU 架构”在运行时其实只有两层含义：指令集能力（x86 vs ARM）和具体微架构（Cortex-A78 vs Skylake）。前者可查，后者需额外特征码。
可行路径：
- Windows：调用
__cpuid查 EAX=0，看cpu_info[0]是否非零且cpu_info[1..3]可读；若返回全零，大概率是 ARM64（x86_64 模式下 CPUID 总可用） - Linux：用
getauxval(AT_HWCAP)或AT_HWCAP2，配合HWCAP_AARCH64、HWCAP2_AVX512F等标志位判断——注意 glibc 版本需 ≥ 2.17，musl 则不支持 - macOS：没有标准 API；只能退回到
sysctlbyname("hw.machine", ...)读字符串，如"arm64"或"x86_64"，但该值受 Rosetta 干扰，不可用于指令调度决策
为什么不能用 uname -m 或 getenv("ARCH")
这类方法看似简单，实则脆弱：
-
uname -m是 shell 命令，依赖/bin/sh和完整用户空间；在 initramfs、容器（scratch镜像）、嵌入式 Linux 中常不可用 -
getenv("ARCH")完全由启动环境注入，Docker 默认不设，systemd-nspawn 可能伪造，无任何保证 - 某些内核配置（如 CONFIG_COMPAT）会让
uname -m返回i686即使 CPU 是 x86_64，仅因进程以 32 位模式运行
真正需要区分架构的场景，应直接检测指令集而非“架构名”
你真正关心的从来不是“这是不是 ARM”，而是“能不能安全执行 ldp 指令”或“有没有 YMM 寄存器”。所以优先做的是指令级探测：
- ARM64：检查
getauxval(AT_HWCAP) & HWCAP_ASIMD（必须有，否则连基本 SIMD 都不支持） - x86_64：先
__cpuid(0, info)确认可用，再查__cpuid(1, info)的 EDX 位域，例如 bit 25 表示 SSE2 - 不要写
#ifdef __aarch64__ run_neon(); #else run_sse(); #endif——这在 Apple Silicon + Rosetta 下会走错分支，且无法适配 AVX-512 等子集
最易被忽略的一点：同一架构下，不同代 CPU 支持的扩展差异巨大。比如 Cortex-A53 不支持 CRC32 指令，但 A72 支持；Skylake 支持 AVX-512，而 Ice Lake 才带 AVX-512_VPOPCNTDQ。硬编码架构名只会让你错过这些关键分水岭。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
