网站与容器迁到VPS后，同一镜像在A机器正常，换到B机器却报“Illegal instruction”；宿主机标注支持AVX2，二进制仍可能崩溃。根因可能是虚拟化层遮蔽标志、编译目标过宽，或镜像基线不一致。部署前要弄清：目标进程能执行哪些指令。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：linkstatic（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
第一层是系统标志。Linux x86环境可从/proc/cpuinfo的flags初筛：avx2表示256位整数向量扩展，aes表示AES-NI硬件加速能力，avx、sse4_2反映向量能力。标志能排除明显不兼容节点，却不是部署许可。
虚拟化层可能遮蔽可见标志，操作系统还须保存YMM/XMM等执行状态；标志存在不等于内核与虚拟化已准备好，缺失也可能源于系统暴露方式。因此，系统标志只是线索，还需另两层证据。
还要区分“处理器支持”与“二进制要求”。用-march=native构建时，AVX2甚至AVX-512代码可能被写进镜像；搬到旧CPU后，常在首次调用相关函数时触发非法指令。部署包的目标架构、最低CPU级别和依赖库参数都应核对。
第二层是编译器能力探测。GCC与Clang的__AVX2__、__AES__、__AVX__宏反映编译目标，目标属性还能生成最小探针。编译成功仅说明代码可生成，实际执行成功才说明CPU与系统状态可用。
探针应短小并置于独立子进程。若AVX2触发非法指令，父进程应回退通用实现，避免服务退出。未显式请求宽指令时，编译器也可能自动改写函数，因此要锁定通用基线，把AVX2、AES-NI设为可选路径。
最终判据来自目标VPS的实际执行结果：用与正式镜像同架构、同运行库的探针，验证指令生成、加载和执行，并对照宿主机标志。容器还要核对基础镜像架构；若标志、编译目标与运行结果冲突，即为二进制兼容性风险，应保守重建或更换节点，勿用强制参数掩盖。
验证后再决定建站与容器调度：静态站点走通用基线，高吞吐服务按探针启用向量或加密加速，不支持的节点进入兼容池。用ServLlama部署时，也应先跑探针再调度，避免面板判断与实际执行相左。
在 x86_64 上，CPUID 暴露处理器功能，但使用 AVX 或 AVX2 还要求系统启用扩展寄存器状态：需确认 OSXSAVE，并通过 XGETBV 检查 XMM、YMM 状态。/proc/cpuinfo 中的标志位只是第一层证据，虚拟机监控器、容器宿主机或 BIOS 设置仍可能屏蔽能力，最终应以目标机实测为准。
CPU 标志位回答“硬件有没有”，编译器能力探测回答“代码是否使用”。-march=native 会把二进制绑定到构建机的指令集；可分发程序宜以通用 x86-64 为基线，再用 __builtin_cpu_supports("avx2") 等接口在运行时选择多版本函数。AES-NI 路径也应如此，让加密库按目标 CPU 选择硬件实现，而不是假定所有节点都支持 aes。
编译器宏只能描述编译目标，不能替代运行机检测。AVX2 与旧版 SSE 代码混用时，还应插入 vzeroupper，避免宽向量切回窄向量时产生状态转换惩罚。AVX-512 可能触发部分 CPU 降频；AES-NI 的收益则取决于数据长度、对齐方式和库实现，不能仅凭标志位推断性能。
最常见的坑，是把“支持某扩展”误认为“整个二进制兼容”。发布物若依赖 x86-64-v2 或 x86-64-v3，旧 CPU、部分云镜像和跨架构机器可能启动即报 SIGILL。应同时保留通用构建与加速构建；共享库也不能因为宿主机较新，就擅自提高调用方所需的指令集基线。
部署前依次检查：①在目标机执行 lscpu 和 grep -m1 '^flags' /proc/cpuinfo，核对 osxsave、avx、avx2、aes；②执行 gcc -march=native -Q --help=target | grep -E "mavx2|maes" 查看实际启用的目标选项；③用 readelf -n 与 objdump -d 检查产物是否声明或包含高阶指令；④在每台目标机运行启动及核心业务冒烟测试，并用 openssl speed 验证 AES 路径；⑤确认探测失败时能回退到通用实现，而不是直接崩溃。
稳妥的原则是“通用基线保证可运行，运行时探测保证可加速”：先验证能力，再启用对应路径，并持续记录 CPU 型号、标志位、二进制基线和测试结果。这样既能利用 AVX2 与 AES-NI 的性能优势，也能避免把硬件差异变成线上事故。
