需先通过__cpuid(1)确认AVX支持（ECX bit28=1），再检查CPUID.07H.ECX bit5以确定AVX2是否启用，且须确保OS已正确配置XSAVE/XRSTOR及XCR0寄存器。
用 __cpuid 检查 AVX2 支持是否开启
AVX2 不是只要 CPU 型号支持就自动可用的——操作系统必须启用 XSAVE/XRSTOR 机制并正确设置 XCR0 寄存器，否则即使硬件支持，执行 AVX2 指令也会触发 #UD（invalid opcode）异常。所以不能只查 CPU 型号，得运行时实测。
标准做法是调用 Windows 的 __cpuid 或 Linux 下的内联汇编 cpuid 指令，查 ECX 的第 5 位（对应 CPUID.07H:ECX.AVX2[bit 5]），但**必须先确认基础 AVX 已就绪**，否则该字段无效：
- 先执行
__cpuid(info, 1)，检查 ECX 第 28 位（AVX[bit 28]）是否为 1 - 再执行
__cpuid(info, 7)，且确保info[0] >= 7（即 CPUID leaf 7 可用），然后检查info[2] & (1 - Linux 下需额外验证
xgetbv(0)返回值的 bit 1 和 bit 2 是否都置位（表示 XMM/YMM 状态已启用）
Linux 下漏掉 xgetbv 就会崩溃
很多示例代码只查 cpuid，忽略 OS 层状态，结果在老内核、虚拟机或未启用 AVX 的容器里一跑 vpaddd 就段错误。根本原因是：CPUID 报告“支持 AVX2”，但内核没把 YMM 寄存器上下文纳入任务切换流程，此时读写 YMM 寄存器会触发 #XM（#GP in 64-bit mode）异常。
安全做法是组合判断：
立即学习“C++免费学习笔记（深入）”；
cpuid(1).ecx & (1 → AVX 基础支持cpuid(7).ecx & (1 → AVX2 指令集支持-
(xgetbv(0) & 0x6) == 0x6→ XMM+YMM 状态已启用（0x6 = bit1 + bit2）
三者缺一不可。少一个，__m256i 运算大概率 SIGILL。
Windows 上 IsProcessorFeaturePresent 不能信
IsProcessorFeaturePresent(PF_AVX2_INSTRUCTIONS_AVAILABLE) 看起来省事，但它只查 CPUID，不查 XCR0，而且从 Windows 8 开始才返回有意义的值。Win7 或某些精简版系统可能始终返回 FALSE，哪怕硬件+内核完全支持。
更糟的是：它不区分“CPU 支持”和“当前进程可安全使用”。所以生产环境必须绕过它，手撸 __cpuid + _xgetbv：
int info[4]; __cpuid(info, 1); bool has_avx = info[2] & (1 << 28); __cpuid(info, 7); bool has_avx2 = (info[0] >= 7) && (info[2] & (1 << 5)); uint64_t xcr0 = _xgetbv(0); bool avx_enabled = (xcr0 & 6) == 6;
编译器没开 -mavx2 也白搭
即使运行时检测全通过，若编译时没加 -mavx2（GCC/Clang）或 /arch:AVX2（MSVC），编译器默认生成 SSE 指令，__m256i 变量会被降级成两个 __m128i 操作，或者直接报错“undefined reference to `__builtin_ia32_vpaddd256`”。
注意点：
- 全局开启影响整个模块，若只想对某函数用 AVX2，用
#pragma GCC target("avx2")（GCC）或__declspec(align(32))+ 内联汇编兜底 - MSVC 的
/arch:AVX2会禁用 AVX-512，但不会自动启用 FMA；如需 FMA，得额外加/arch:AVX2,FMA - 静态链接 libc 时，某些旧版 glibc 的
memcpy实现会在内部试探 AVX2，若你禁用了但 runtime 检测逻辑有 bug，反而引发冲突
最稳的路径：运行时检测 + 编译器显式启用 + 函数级 fallback（比如 SSE 路径）。别指望一次检测保终身。
