运行时检测CPU是否支持AVX指令集必须通过CPUID指令实测，而非编译器宏；调用__cpuid(info, 1)后检查info[2]第28位（AVX）和info[3]第25位（SSE）。
运行时检测 CPU 是否支持 AVX 指令集
不能靠编译器宏（如 __AVX__）判断运行环境——它只说明代码被编译时启用了 AVX，不代表当前 CPU 支持。必须用 CPUID 指令实测。
关键步骤是调用 __cpuid（MSVC）或 __cpuid_count（GCC/Clang），查 ECX 的第 28 位（AVX）和 EDX 的第 25 位（SSE）：
-
__cpuid(info, 1)返回基础功能标志，SSE 支持看info[3] & (1 - AVX 需额外检查
__cpuid(info, 7)的info[2] & (1 ，但更可靠的是先确认 XGETBV(0) 返回的 XCR0[2:1] == 0b11（表示 OS 已启用 XMM/YMM 寄存器） - 漏掉 XGETBV 检查会导致 AVX 指令在部分系统上触发 #UD 异常，即使 CPUID 显示支持
Windows 下用 IsProcessorFeaturePresent 快速兜底
这个 API 封装了 CPUID + 系统状态检查，适合不想手写内联汇编的场景，但覆盖有限：
- 支持
PF_SSE_ENABLED、PF_AVX_ENABLED、PF_AVX2_ENABLED，不支持 AVX-512 - 返回
true表示 CPU 支持 且 OS 已启用对应寄存器上下文（即通过了 XGETBV 验证） - 注意：它不区分 SSE2/SSE4.1，只报告“SSE 是否可用”，精度不如直接 CPUID
Linux/macOS 下用 cpuid 指令 + xgetbv 组合验证
POSIX 系统没有现成 API，需内联汇编或调用 __get_cpuid（GCC 内置）配合 _xgetbv（需定义 __xgetbv）：
立即学习“C++免费学习笔记（深入）”；
unsigned int info[4];
if (__get_cpuid(1, &info[0], &info[1], &info[2], &info[3])) {
bool has_sse = info[3] & (1U << 25);
bool has_avx = false;
if (__get_cpuid(7, &info[0], &info[1], &info[2], &info[3])) {
has_avx = info[2] & (1U << 28);
}
// 必须再检查 xgetbv(0) 低两位是否为 0b11
unsigned long long xcr0 = _xgetbv(0);
has_avx &= ((xcr0 & 6) == 6); // XMM+YMM enabled
}
-
__get_cpuid在<cpuid.h>中，非所有 GCC 版本都默认启用，可能需加-march=native -
_xgetbv是编译器内置函数，但需确保目标平台支持（x86_64），32 位需用内联汇编 - macOS 对
xgetbv限制更严，某些版本会拦截该指令，此时只能依赖sysctlbyname("hw.optional.avx")（仅限 Intel Mac，M 系列不适用）
避免编译期与运行期支持错配的典型坑
最常见错误是：编译时加了 -mavx，但部署到老 CPU 上直接崩溃；或者用 __AVX__ 宏做条件编译，结果在不支持 AVX 的机器上仍执行了 AVX 指令路径。
- 永远不要用编译器宏决定运行时分支逻辑，它们只控制代码是否被编译进二进制
- 动态分发（dispatch）必须基于运行时检测结果，比如用函数指针表：
auto kernel = has_avx ? avx_kernel : sse_kernel; - 检测逻辑本身不能含 AVX 指令（否则未检测前就崩了），所有检测代码需用通用 x86 指令编写
真实环境中，XGETBV 检查比单纯 CPUID 多一步，但跳过它等于把兼容性交给运气。
