最可靠方式是通过WMI查询Win32_ComputerSystem的Manufacturer和Model字段，结合SystemType交叉验证；C#需用System.Management命名空间并加try-catch，PowerShell中Get-ComputerInfo仅适用于5.1+且非嵌入场景，注册表和CPU指令检测均有明显局限性。
怎么用 WMI 查询 Win32_ComputerSystem 判断虚拟机
最可靠的方式是查 WMI 中的 Manufacturer 和 Model 字段，真实物理机通常显示 Dell/HP/Lenovo 等厂商名，而虚拟机基本固定为 VMware/VirtualBox/QEMU/Microsoft（Hyper-V）等。
实操建议：
- 必须用
System.Management命名空间，引用System.Management.dll - 查询前加 try-catch，WMI 在某些受限环境（如最小化 Server Core、容器内）可能不可用或超时
- 不要只看
Manufacturer，有些云主机（如 AWS EC2）也返回 Amazon，但它是真物理集群，需结合Model（Amazon EC2）和SystemType（Virtual Machine）交叉判断 - 示例关键代码：
var query = new ObjectQuery("SELECT Manufacturer,Model,SystemType FROM Win32_ComputerSystem");
Get-ComputerInfo 在 PowerShell 里能直接用吗？
可以，但仅限 PowerShell 5.1+（Windows 10/Server 2016 起），它底层也是调 WMI，封装更友好，适合快速验证，不适合嵌入 C# 主程序。
常见错误现象：
- 在旧版 PowerShell（如 2.0）运行报错：
The term 'Get-ComputerInfo' is not recognized - 返回结果里
CsManufacturer和CsModel字段为空——说明当前用户无 WMI 权限，需以管理员身份运行 - 部分精简系统（如 Windows Nano Server）不支持该命令，会直接报错退出
C# 里用注册表检测 Hyper-V 的坑在哪
查注册表 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters 是常见做法，但它只对 Hyper-V Guest 有效，VMware/VirtualBox 完全不写这个键，容易误判为“非虚拟机”。
使用场景限制明显：
- 仅适用于已安装 Hyper-V Integration Services 的 Windows Guest
- Windows Server 2012 R2 及更早版本中，该路径下键值可能不存在，即使运行在 Hyper-V 上
- 若程序跑在容器（如 Windows Container）里，注册表视角是宿主机视图，但实际隔离层可能是 Hyper-V 隔离，此时注册表检测完全失效
- 别依赖
HostName或VirtualMachineID是否存在来判断，它们可能被策略清空或未初始化
为什么不能只靠 CPU 特性（如 Cpuid）检测虚拟化
现代 CPU 的 cpuid 指令确实能返回虚拟化标识（如 HYPERVISOR bit），但 C# 没有安全执行 cpuid 的标准方式——需要 P/Invoke 调用内联汇编或驱动级接口，极易触发 .NET Core/.NET 5+ 的 AOT 编译失败或 AVX 指令异常。
性能与兼容性影响：
- 在 ARM64 Windows（如 Surface Pro X）上，
cpuid本身不存在，对应指令是mrs，跨架构维护成本高 - 部分杀毒软件或组策略会拦截低级 CPU 指令调用，导致程序崩溃而非优雅降级
- 云服务商（如 Azure）近年默认开启 Nested Virtualization，宿主机本身已是虚拟机，但
cpuid返回的是“物理 CPU”，无法反映真实层级
真正难处理的是混合环境：比如一台 VMware 虚拟机里跑 Docker Desktop（基于 Hyper-V），再启动一个 Linux 容器——此时 WMI 查到的是 VMware，注册表查不到 Hyper-V Guest 键，CPU 指令又显示无 hypervisor。这种嵌套层级没统一解法，得按具体用途取舍检测目标。
