最可靠方式是交叉验证CPUID（查0x40000000获取vendor ID如"VMwareVMware"）、DMI/SMBIOS（如/sys/class/dmi/id/product_name）及虚拟设备ID（如VEN_15AD），单点检测易被云平台隐藏或伪造。
检测 CPUID 指令返回的虚拟化标识
现代虚拟机（如 VMware、VirtualBox、Hyper-V）在 CPUID 指令执行时会暴露特定标志，这是最可靠且无需管理员权限的检测方式。关键看 cpuid 叶子 0x1 和 0x80000001 的 ECX/EDX 位，以及扩展叶子 0x40000000 是否存在。
实操建议：
- 用内联汇编或
__cpuid（MSVC）/__get_cpuid（GCC/Clang）调用 CPUID；先查0x40000000：若EAX返回值 ≥0x40000001，说明是 Hyper-V 或 KVM/QEMU（带hv_vendor_id字符串）； - 再查标准叶子
0x1：若ECX[31]（即 VMX 标志）为 1，可能运行在支持 Intel VT-x 的物理机上，不能直接断定是虚拟机；需结合其他线索； - 查
0x80000001：若EDX[31]（SVME 标志）为 1，同理仅表示 AMD SVM 支持，不等于正在虚拟机中运行； - 注意：部分云环境（如 AWS Nitro、Azure Nested Virtualization）会隐藏这些标志，此时该方法失效。
读取 DMI/SMBIOS 信息识别厂商字符串
虚拟机通常在 BIOS/DMI 表中硬编码明显标识，比如 VMware、VirtualBox、QEMU、Microsoft Hv。Linux 下可读 /sys/class/dmi/id/product_name 或 /sys/class/dmi/id/sys_vendor；Windows 下可用 WMI 查询 Win32_ComputerSystem 的 Manufacturer 和 Model 属性。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 普通用户无权读取
/sys/firmware/dmi/tables/（需 root），但/sys/class/dmi/id/下多数字段已开放； - 某些加固虚拟机（如 Google Cloud 的 Shielded VM）会抹除或伪造 DMI 字段，返回空或通用值（如
Google而非Google Compute Engine）； - Windows 上若 WMI 服务被禁用或权限受限，
Get-WmiObject会抛出Access denied或空结果；建议 fallback 到注册表HKEY_LOCAL_MACHINE\SYSTEM\HardwareConfig\Current中的SystemBiosVersion值（含VMware等字样）。
检查特定设备或驱动痕迹
虚拟硬件栈会暴露独特设备 ID 或驱动名称，比 CPUID 更难屏蔽，适合辅助验证。
使用场景与要点：
- Linux：检查
/proc/scsi/scsi（VMware 的VMware, VMware Virtual S SCSI）、/proc/ide/hd*/model（VirtualBox 的VBOX HARDDISK）、lspci -v输出中是否有VMware SVGA、VirtualBox Graphics Adapter； - Windows：枚举 PnP 设备，查找
VEN_15AD（VMware PCI Vendor ID）、VEN_80EE（VirtualBox）、PCI\VEN_1414（Hyper-V Synthetic Video）；也可查HKLM\SYSTEM\CurrentControlSet\Services\*下是否存在vmhgfs、VBoxGuest、vmicvss等服务名； - 性能影响极小，但需注意：容器（如 Docker）不触发这些设备特征，该方法无法区分容器与宿主机；
- 某些云平台（如阿里云 ECS）使用定制 VirtIO 驱动，其
VEN_1AF4并非虚拟机独有，需结合DeviceDesc字符串进一步判断（如含Alibaba Cloud）。
时间戳偏差与 RDTSC 异常检测（慎用）
虚拟机监控器（VMM）拦截 RDTSC 指令可能导致时间戳不可靠，但该方法误报率高、兼容性差，仅作最后手段。
为什么这样做：
- 真实 CPU 的
RDTSC返回周期计数，而部分 VMM（尤其旧版 VirtualBox）会返回模拟值，连续两次调用差值异常小（rdtsc后立刻rdtsc，差值常为 0 或个位数）； - 但现代 VMM（如 VMware Workstation 17+、QEMU 7.0+）已默认启用
rdtscppassthrough 或 TSC virtualization，该检测完全失效； - 超线程、频率调节（Intel SpeedStep）、系统中断都可能造成类似偏差，单独依赖此法极易误判；
- 若仍要尝试，务必加循环多次采样（≥100 次），排除噪声，并只在其他方法均不确定时启用。
真正可靠的检测永远需要多信号交叉验证——单点特征可能被绕过或伪造，而 CPUID + DMI + 设备 ID 同时命中，才值得信任。别忘了，有些生产环境明确禁止虚拟机检测（如反作弊系统、DRM），强行探测反而触发风控。
