运行时检测CPU是否支持AVX2最可靠方式是执行CPUID指令：Windows调用__cpuid(0x00000007)，检查cpuInfo[1]第5位；Linux/macOS调用__get_cpuid(7, &eax, &ebx, &ecx, &edx)，检查ebx第5位，且须先用CPUID(0)确认指令可用。
怎么在运行时检测 CPU 是否支持 AVX2
直接读取 CPUID 指令是最可靠的方式，__cpuid（Windows）或 __get_cpuid（GCC/Clang）能查出硬件真实能力，不依赖编译选项或 OS 声明。
常见错误是只看编译器是否允许 -mavx2，但即使开了这个 flag，程序跑在老 CPU 上仍会触发 Illegal instruction——因为编译器没帮你做运行时分支。
- Windows 下用
__cpuid(int cpuInfo[4], int infoType)，查infoType = 0x00000007时，cpuInfo[1]的第 5 位（bit 5）为 1 表示支持 AVX2 - Linux/macOS 下用
__get_cpuid(7, &eax, &ebx, &ecx, &edx)，同样看ebx的 bit 5 - 别漏掉前置检查：先调一次
__get_cpuid(0, ...)确认 CPUID 指令本身可用，否则在极老 CPU（如奔腾早期）上会 crash
为什么不能只靠编译器内置宏判断
__AVX2__ 这类宏只是告诉“当前编译是否启用了 AVX2 支持”，和 CPU 实际能力完全无关。它由 -mavx2 或 /arch:AVX2 触发，属于编译期开关。
典型翻车场景：你用 AVX2 编译了一个库，用户在 i5-2400（Sandy Bridge，无 AVX2）上一运行就 SIGILL——因为宏只管编译，不管执行。
立即学习“C++免费学习笔记（深入）”；
-
__AVX2__在未开启-mavx2时一定未定义，哪怕 CPU 支持也没用 -
__AVX2__在开启-mavx2后一定定义，哪怕目标 CPU 是 Pentium 4 - 真正需要的是“CPU 支持 + 编译器生成对应指令 + 运行时跳转”三者闭环，缺一不可
如何安全地分发多版本代码路径
最轻量的做法是函数指针 + 运行时派发，避免整个模块重复编译。不要用模板特化或宏塞满源码，维护成本太高。
容易踩的坑是把 dispatch 逻辑写在 hot path 里，每次调用都查 CPUID——这比指令本身还慢。必须只查一次，缓存结果。
- 用静态局部变量 +
std::call_once初始化函数指针，例如：static auto impl = init_impl(); - 初始化函数里调用
__get_cpuid判断，返回指向process_avx2()或process_fallback()的指针 - 确保 fallback 版本只用 SSE2 或通用 x86 指令，别误用 AVX 寄存器（如
xmm0和ymm0共享物理寄存器，混用可能破坏数据）
ARM 架构下怎么类比处理（比如 SVE）
x86 的 CPUID 在 ARM 上没有直接等价物，得靠 getauxval(AT_HWCAP) 或 getauxval(AT_HWCAP2) 查系统提供的硬件能力位图。
注意 Android 和旧版 Linux 内核可能不暴露完整 HWCAP，尤其 SVE 需要内核 ≥ 4.17 且用户态启用（/proc/sys/abi/sve 可写），光看 AT_HWCAP 返回值可能误判。
- 查 SVE：检查
getauxval(AT_HWCAP2)的 bit 1（HWCAP2_SVE） - 查 AES 指令：看
getauxval(AT_HWCAP)的 bit 3（HWCAP_AES） - 别依赖
__aarch64__宏——它只表示目标架构是 aarch64，不说明 CPU 有 AES 或 CRC 指令
vpaddd 上。对齐方式、栈帧布局、甚至链接器脚本，都得随指令集路径同步调整。 
