斯迈尔齿科如果你也遇到过这种场景——在VMware Workstation里辛辛苦苦建好Ubuntu 20.04虚拟机，点下“开启此虚拟机”，屏幕闪了两下BIOS画面后直接黑屏，或者电脑在安装进度条快到100%的时候整个VMware窗口突然消失，再下来一个“虚拟机已崩溃，正在尝试重启”的弹窗——那么这篇东西就是为你写的。先说结论：这类崩溃绝大多数不是Ubuntu镜像本身的问题，而是“宿主机环境、虚拟硬件配置、显卡驱动加载”这三者互相打架的结果。
我自己在给多台不同电脑装Linux虚拟机时，撞见过黑屏、蓝屏、关机时卡死、VMware进程抢占CPU等各种“崩溃”方式，几乎每次都被外观带偏了排查思路。这篇文章不打算讲教科书式的虚拟机原理，而是把我实际撞过、也帮别人处理过的高频崩溃点按现象分类，从宿主机到VMware设置再到Ubuntu内核参数，逐层说清每类崩溃的排查链路。适合所有在Windows上用VMware装Ubuntu 20.04，遇到安装中途崩溃、启动黑屏、装完系统反复重启的朋友，不管你是刚接触虚拟机还是已经踩过几次坑，都能对号入座找到对应解法。
1. 崩溃的第一现场：先判断你属于哪一类，再决定往哪查
虚拟机“崩溃”这个说法其实很模糊，不同人说出“崩溃”两个字时，看到的界面完全不是一回事。我接到的咨询里，至少有四种完全不同的现象都被统称为“崩溃”：安装向导完成后一开机就黑屏、安装过程中虚拟机窗口闪退、宿主机自己蓝屏重启、安装完成登录进去后随机卡死。这四种现象背后的原因没有太多重合度，所以第一步一定不是去翻教程，而是先确认你看到的是哪一种现场。
1.1 引导安装界面都进不去的黑屏
这是最普通也最让人头大的一个状态：虚拟机电源开着，虚拟机窗口里只有一片黑，也有的是黑底上面一个白色横杠在闪，远远看着像系统卡死了。很多朋友在这时候就会去重装VMware、换个Ubuntu版本，其实这里大部分情况不是虚拟机崩溃，而是Ubuntu桌面版的图形化引导界面在VMware的虚拟显卡上没能顺利初始化。
Ubuntu 20.04默认的引导过程会直接加载内核自带的开源显卡驱动，在虚拟机上这个驱动有时会尝试去初始化并不存在的物理GPU设备，然后卡在启动流程中不再往下走。黑屏但虚拟机进程还活着、CPU没占满，多半就是这个原因。这类现象通常能用nomodeset内核参数解决，后面第4章会详细说操作。
1.2 安装进度条中途闪退或窗口消失
这类“崩溃”看起来吓人：VMware窗口整个没了，或者弹出一个“VMware Workstation 已停止工作”的Windows错误窗。如果宿主机没蓝屏，只是VMware进程退出，优先怀疑虚拟硬件配置与当前宿主机的虚拟化特性不匹配；如果同时宿主机也蓝屏，那基本跑不出内存条不稳定、电源供电不足、Hyper-V遗留的底层冲突这几个物理层原因。
1.3 Ubuntu装完进入系统后反复崩溃
第一次重启后能看到登录界面，但输入密码进入桌面后一会儿就卡死，或者屏幕出现花屏、残影，然后整个系统无响应。这类现象背后最核心的问题往往是两个：一个是虚拟显卡驱动没整利索，另一个是VMware Tools没有正常安装，导致虚拟机在等待虚拟硬件响应时超时。看起来是“系统崩溃”，实际上是虚拟化工具链缺了一环。
1.4 VMware 弹窗里出现不认识的错误码
VMware自己的错误弹窗类型也不少，遇到“Guru Meditation”“vcpu-0”“内部错误”“MKS: Connection refused”这些字样，处理起来就比单纯黑屏更费劲。这类错误码通常意味着虚拟机的CPU执行状态和宿主机无法对齐，常见于BIOS里的VT-x/AMD-V没开全、嵌套虚拟化选项设置错误、或者宿主机的杀毒软件/安全软件拦截了VMware的虚拟化驱动。遇到弹窗别急着截图求人，先把错误码原文记下来，再对着VMware日志分析，往往真相就在日志最后几行。
为了方便对号入座，我把这四类现场汇总成一张参考表：
| 现象 | 优先怀疑方向 | 第一步操作 |
|---|---|---|
| 开机黑屏、横杠闪烁 | 显卡驱动初始化失败 | 引导时加 nomodeset |
| 安装中VMware窗口闪退 | 虚拟硬件配置/宿主机虚拟化设置 | 核对VMware版本与VT-x设置 |
| 宿主机蓝屏重启 | 物理内存、Hyper-V残留、电源 | 进行内存诊断，关闭Windows底层虚拟化 |
| 登录后卡死/花屏 | VMware Tools缺失、3D加速不兼容 | 安装 open-vm-tools-desktop |
拿到这层判断之后，后面所有步骤才会有明确方向。有些人一看到崩溃就去改虚拟机配置，改了一堆，最后发现是ISO镜像文件下载损坏，白白浪费一下午，所以先定性再动手永远不亏。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 宿主机的前置检查：很多崩溃根本轮不到Ubuntu“背锅”
处理虚拟机崩溃有个铁律：先从虚拟机外面的世界查起。我见过太多人在虚拟机设置里反复折腾，结果根源在宿主机BIOS或者Windows组件上。VMware运行在宿主机之上，宿主机提供虚拟化能力的方式稍微不对，虚拟机内部再怎么调整也是白费。
2.1 BIOS里的虚拟化开关是最容易被忽略的“崩溃源头”
不管你的CPU是Intel还是AMD，VMware Workstation要创建一个可用的虚拟CPU环境，都依赖处理器里内置的硬件虚拟化指令。Intel平台叫VT-x（虚拟化技术），AMD平台叫SVM（安全虚拟机）。很多主板出厂时默认把这项功能关掉，但VMware在安装阶段未必会主动提示你，等你真正解析到需要复杂指令的Ubuntu内核时，虚拟机就可能在启动或安装中途突然崩溃退出。
检查方式很简单：重启电脑进BIOS设置界面（开机时反复按F2、Del、F10，不同主板入口不一样），在“Advanced”或“CPU Configuration”菜单里找到“Intel Virtualization Technology”或“SVM Mode”，确认它的状态是Enabled。改完保存退出，再重新打开VMware。
还有一个更快捷的验证方法——在Windows的任务管理器里直接看。按Ctrl+Shift+Esc打开任务管理器，切到“性能”选项卡，点“CPU”，看右下角“虚拟化”那一行是“已启用”还是“已禁用”。如果是禁用，那先别折腾虚拟机的任何配置，回BIOS开开关。
2.2 与 Hyper-V 的冲突：Win10/11 上 VMware 崩溃的隐形元凶
Windows 10和Windows 11默认会把基于虚拟化的安全（VBS）和内存完整性（核心隔离）打开，同时WSL2、Windows沙盒、设备加密这些功能也都依赖Hyper-V。问题在于，VMware Workstation的虚拟机管理员程序和这些Windows自带的Hypervisor抢同一个硬件资源。当Hyper-V也在运行时，VMware只能以“嵌套虚拟化”的方式工作，底层指令翻译多了一层，部分Ubuntu内核操作一旦触碰到敏感指令，虚拟机就崩了。
这种冲突最常见的表现是：VMware可以打开，虚拟机也能创建，但只要Ubuntu一启动到内核加载阶段，VMware就闪退，或者宿主机直接蓝屏。你有没有装过WSL、Docker Desktop或者开过“内存完整性”，如果装过，Hyper-V的残留几乎必然存在。
处理方式不是非黑即白，看你日常还要不要用WSL2和Docker：
- 如果你只用VMware，可以关闭Windows沙盒和虚拟机平台功能：控制面板 → 程序和功能 → 启用或关闭Windows功能 → 取消勾选“Hyper-V”和“虚拟机平台”，重启后VMware独占虚拟化资源，崩溃概率大幅下降。
- 如果你日常也需要WSL2，就得让VMware和Hyper-V共存。建议用VMware Workstation 16或17较新版本，它们对Hyper-V共存的支持比老版本强很多，另外在虚拟机设置里取消勾选“基于虚拟化的安全性”相关的嵌套选项。实测下来，共存模式下稳定性不如独占模式，装Ubuntu还是建议先临时关掉Hyper-V功能，装完系统再打开。
2.3 镜像来源和文件校验：安装中途崩溃的隐形原因
Ubuntu 20.04的官方ISO镜像大约2.6GB，很多朋友为了下载速度快去第三方站点找网盘链接，结果拿到的是被二次压缩过的文件，甚至在解压过程中就已损坏。安装程序在读取损坏文件时会随机出现“无法读取文件”“分区格式化失败”“GRUB引导安装失败”之类的错误，表面看起来就像系统崩溃了。
正规做法是只到Ubuntu官网或国内认可度高的镜像站下载，下载完成后顺手做一次SHA-256校验。Windows命令提示符或PowerShell里执行：
powershell复制Get-FileHash .\ubuntu-20.04.6-desktop-amd64.iso -Algorithm SHA256
把算出来的哈希值和官方发布的SHA256值比对。校验一致再开始安装，能过滤掉大约三成的“安装中途崩溃”。额外提一句：Ubuntu 20.04有多个小版本，比如20.04.3、20.04.6，尽量下载20.04.6这个最终版本，它累积了大量硬件兼容性补丁，在虚拟机里的安装体验比早期版本稳得多。
2.4 物理内存不足导致的假崩溃
Ubuntu桌面版官方要求至少2GB内存，但“能装”和“装得稳”是两回事。如果你把虚拟机的内存分配得很小，比如只给了1GB，Ubuntu的安装程序启动后就会因为内存耗尽而卡在某一步，或干脆黑屏。另一个极端是宿主机本身只有8GB内存，你给虚拟机分了6GB，Windows系统自己的后台进程不够用，内存压力一大，整机都可能无响应，看着也像“崩了”。
建议的起步配置是给虚拟机分配4GB内存，2核CPU，磁盘40GB。这个配置在当前主流电脑上不会给宿主机造成明显压力，也能让Ubuntu桌面版跑得比较顺。如果宿主机只有8GB物理内存，那就把虚拟机内存控制在3GB左右，同时确保关闭Windows里的部分后台驻留程序，不要一边开着几十个浏览器标签一边装虚拟机系统。
3. 虚拟硬件设置的四个“坑位”：创建向导里的选择决定了后面的稳定性
很多人创建虚拟机的时候嫌细节繁琐，全程点“下一步”默认选项，等系统崩了又来找原因。其实VMware创建向导里的几个下拉框，直接决定了虚拟机里那套虚拟硬件长什么样，而Ubuntu 20.04对某些硬件组合确实存在兼容性问题。
3.1 客户机操作系统类型：不要偷懒选“Other Linux”
如果创建虚拟机时没有正确选择客户机操作系统类型，VMware会让虚拟机的PCI设备、磁盘控制器、ACPI电源管理走一套通用兼容逻辑，而不是针对Linux发行版优化后的配置。崩不崩溃取决于运气，但实际观察中，选错类型更容易出现磁盘读写慢、按键无响应、屏幕分辨率无法调整这类问题，严重的会在系统安装完成后首次重启时直接卡死在品牌Logo界面。
创建向导“客户机操作系统”一步，如果你要装的是Ubuntu 20.04桌面版，就选“Linux”，版本下拉框选“Ubuntu 64位”。不要因为手头ISO是桌面版就选成“Ubuntu”（因为不带“64位”），VMware在64位模式下会开启额外的64位客户机支持，包括更符合Linux内存管理的默认项。一个很小但关键的选择，能避免后面一堆看不见摸不着的稳定性问题。
3.2 固件类型选BIOS还是UEFI：切换一下就能解决部分启动崩溃
VMware创建虚拟机时，固件类型默认是BIOS，也提供UEFI选项。Ubuntu 20.04在这两种固件下都能正常安装，但某些主板或虚拟化环境下，UEFI固件的启动流程会在部分Linux发行版上触发内核崩溃。
如果在安装Ubuntu过程中屏幕出现“Kernel panic - not syncing: Attempted to kill init”这类字样，或者GRUB引导菜单加载时就卡死，不妨直接关掉虚拟机，在虚拟机目录的.vmx文件中改一行配置，或者编辑虚拟机设置里“虚拟机→设置→选项→高级→固件类型”为“UEFI”，然后重新开机再试。同样，如果当前是UEFI模式出现问题，也可以换成BIOS试试。这是我用过的最快判断固件兼容性的方法，基本五分钟就能得出结果。
3.3 CPU分配：核数不是越多越好
宿主机的CPU核心很多，于是有人给虚拟机分配了8核甚至16核，心想这样Ubuntu肯定跑得快。但虚拟机CPU的核心数量和虚拟化性能并非线性关系，分配过多虚拟CPU反而让VMware的调度器频繁在物理核心之间切换线程，导致虚拟机出现莫名其妙的卡顿和崩溃。
更常见的坑是在Windows上启用Hyper-V的前提下给虚拟机关联分配CPU，嵌套虚拟化会额外消耗大量性能。给Ubuntu 20.04桌面版分配2到4个虚拟CPU就够日常使用。如果你要跑的是深度学习模型训练，那本来也不该用VMware这类桌面虚拟化软件，换成物理机或WSL2更合适。在虚拟机设置里把“虚拟化引擎”下的“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”勾选起来，性能和稳定性都会提升一截。
3.4 磁盘控制器类型与SCSI、SATA、NVMe的选择
VMware为虚拟机提供多种磁盘连接方式：我的SCSI、LSI Logic SAS、SATA、还有NVMe。Ubuntu 20.04默认支持这些主流接口，但如果你在创建虚拟机时选了旧式SCSI控制器（常见的默认选项），在某些版本的Ubuntu内核上会出现轮盘转速异常、磁盘I/O卡死的问题。
经验判断是：普通使用场景优先选择SATA或NVMe。SATA最稳妥，兼容性最高，安装过程几乎不会因为磁盘控制器出岔子。NVMe速度更快，Ubuntu 20.04也支持良好，如果你的宿主机是SSD，体验会更好。默认的LSI Logic SCSI其实也是成熟方案，但真遇到I/O相关崩溃，把它切到SATA再做一次重装是零成本尝试。磁盘类型也能在创建后修改，但涉及引导区域，不如创建时就选对省事。
4. 安装中途、首次启动环崩的“三板斧”：nomodeset、3D加速与重做引导
当系统已经进入安装界面，或者在安装过程中、安装完成后首次重启时崩溃，常见原因比装前配置更集中。这里说的三个操作覆盖了大多数实际现场，每招都经过了大量实例验证。
4.1 引导参数追加 nomodeset：黑屏首选解
这是解决Ubuntu黑屏最经典、也是最应该掌握的一招。Ubuntu桌面版的安装镜像启动时，默认会让内核加载显卡驱动模块，但在VMware的虚拟显卡环境下，加载过程常会失败，导致屏幕没有信号输出。nomodeset参数的意思是告诉内核不要主动做显卡模式设置，把显示控制权交给后续的驱动或基础的VGA输出。
操作流程：开机进入虚拟机后，在GRUB引导菜单出现时，先选中“Try or Install Ubuntu”，按键盘上的字母“e”进入编辑模式，找到以“linux”开头的那一行，在末尾的空格后追加：
bash复制quiet splash nomodeset
添加完成后按Ctrl+X或F10保存并启动。如果这次能顺利进入Ubuntu界面，就说明显卡驱动加载确实有问题。安装完系统之后，还要把同样的参数持久化写入GRUB配置，否则重启后黑屏会再次出现。
持久化方法：进入系统后在终端里编辑GRUB配置文件：
bash复制sudo nano /etc/default/grub
找到 GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" 这一行，改成：
bash复制GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"
保存后执行：
bash复制sudo update-grub
注意，加了nomodeset后系统显示性能会有所下降，但换来的是稳定。在VMware里跑Ubuntu不做图形渲染的话，这点性能损失基本感知不出来。
4.2 关闭虚拟机的“加速3D图形”选项
很多人在VMware里给Ubuntu开启“加速3D图形”，觉得这样才能发挥GPU能力，实际上这反而是登录后崩溃的元凶之一。VMware的3D加速功能通过虚拟GPU向客户机提供OpenGL支持，但Ubuntu 20.04默认的GNOME桌面环境本身就需要针对性的图形栈适配，如果虚拟GPU与宿主机真实显卡驱动之间存在兼容断层，轻则花屏，重则桌面会话直接崩掉。
建议是：在虚拟机电源关闭状态下，右键虚拟机名 → “设置” → “显示器”，取消勾选“加速3D图形”，同时把“最大分辨率”调整为合理值。日常使用如果只是写代码、跑终端、看网页，关闭3D加速几乎不影响体验，稳定性却直线上升。
4.3 安装完成后进入不了系统：GRUB修复与恢复模式
如果你已经安装完成，但在重启后卡在GRUB命令行或者进入一个黑屏、只有光标闪烁的界面，多半是引导程序出问题。最简单的排查方式是进入Ubuntu的恢复模式——启动菜单选“Advance options for Ubuntu”，里面会有“恢复模式”选项，进入后选择“网络”启用网络，再选“修复损坏的软件包”，顺序执行。
有些场景下，恢复模式也进不去，GRUB直接停在grub>命令行。这时可以手动从分区启动内核，执行以下命令定位系统分区：
bash复制ls
set root=(hd0,msdos1)
linux /vmlinuz root=/dev/sda1
initrd /initrd.img
boot
能进入系统后，立刻执行sudo update-grub，然后重装GRUB引导：
bash复制sudo grub-install /dev/sda
这套组合是修复引导崩溃的通用手段，适用面不止VMware，物理机同样有效。
4.4 快照和备份习惯：崩溃处理成本最低的减负方法
安装完成并做好基础配置后，建议立即关闭虚拟机，创建一个“干净系统”快照。后面验证一个内核参数或者装一个驱动崩了，恢复快照只要十几秒，不需要重装系统。这个习惯成本极低，收益却非常大，尤其是当你需要反复测试不同显卡驱动时，快照就是后悔药。
5. 装好系统后的“二次崩溃”：VMware Tools与显卡驱动是主要纠缠点
系统装好、nomodeset也加了，按理说应该稳定了，但不少人在这时候遇到新的崩溃——登录桌面没多久就死机、鼠标键盘无响应、屏幕黑一下又恢复，严重的直接重启虚拟机。这轮问题集中在虚拟机和宿主机之间的“桥接层”，也就是VMware Tools。
5.1 open-vm-tools-desktop是必须装的
很多教程会让用户在虚拟机里挂载VMware Tools安装镜像去安装。但在Ubuntu 20.04上，优先推荐直接安装发行版自带的open-vm-tools和open-vm-tools-desktop包，这是VMware官方与Linux社区共同维护的开源版本，和Ubuntu内核的配合度比VMware镜像里附带的老版本更好。
系统第一次进入桌面后，先在终端执行：
bash复制sudo apt update
sudo apt install open-vm-tools open-vm-tools-desktop
安装完后重启虚拟机。重启后剪贴板共享、窗口自适应分辨率、文件拖拽这些功能就正常了。更重要的是，open-vm-tools会注册一个虚拟硬件心跳服务，让VMware宿主机能正确管理虚拟机状态，避免因为虚拟机一直不响应而触发假死。
5.2 别在VMware里额外折腾显卡驱动
网上大量Ubuntu 20.04安装NVIDIA显卡驱动的教程，这些教程大多默认你是物理机。虚拟机里跑Ubuntu，根本不需要也尽量不要安装任何专有显卡驱动。VMware提供的虚拟显卡叫VMware SVGA，Ubuntu内核自带的开源驱动已经能驱动它。折腾NVIDIA专有驱动装进虚拟机，十有八九会导致内核模块冲突，重启后直接崩到登录界面都进不去。
如果你确实需要做GPU相关的开发，在VMware里干这事不是好选择——虚拟显卡没法直通给Ubuntu使用，除非你配置PCI直通（这需要额外的硬件支持和复杂配置）。普通工作场景，关闭3D加速、用内核自带驱动、装好open-vm-tools-desktop，才是稳定运行的关键组合。
5.3 花屏和桌面卡死的“最后一根稻草”：分辨率与缩放
有些时候崩溃不是突然蓝屏，而是先出现桌面花屏、字体模糊、窗口撕裂，然后再卡死。这通常是分辨率自适应机制在作怪。VMware在装了open-vm-tools后，会自动调整分辨率以匹配虚拟机窗口大小。但如果你手动在Ubuntu的显示设置里选了宿主机不支持的刷新率或缩放比例，就可能让虚拟显卡进入异常状态。
遇到花屏，先尝试按Ctrl+Alt+F2切到纯字符终端，然后用Ctrl+Alt+F1切回图形界面，这一步能触发显示栈重新初始化。如果崩溃后直接无法恢复，可以在显示设置里把分辨率改成16:9的常规值（比如1920x1080）并关闭分数缩放。不要选“自动调整窗口大小”，固定分辨率跑反而稳。
5.4 交换空间不够导致的“假死”
Ubuntu默认在安装时自动创建交换分区，大小一般和内存相当或更小。如果你在虚拟机设置里把内存调大，但交换分区没有同步扩大，当多个应用同时吃内存时，系统会在内存和交换分区之间的反复读写中卡成PPT状态，严重时鼠标都动不了，给人“崩了”的感觉。
打开终端看内存压力：
bash复制free -h
如果Swap行显示0B，说明根本没有可用的交换空间，建议增加一个swapfile：
bash复制sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
然后写进fstab保证重启生效：
bash复制echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
这个操作尤其适合分配给虚拟机的物理内存不多的情况，能让系统在内存吃紧时依然保持响应，避免看起来像崩溃的长时间无响应。
6. 从日志里提取“法医证据”：崩溃之后别再瞎猜了
如果前面的方法都试过，崩溃还是阴魂不散，那就别再一遍遍重装系统碰运气了，学会读日志。日志是排查虚拟机崩溃时最值钱的线索来源，宿主机和虚拟机两头都有日志可查。
6.1 宿主机端的 vmware.log
每个虚拟机目录下都有一个 vmware.log 文件，记录着这台虚拟机电源开启以来的几乎所有底层事件。默认路径一般在这个位置：
code复制C:\Users\你的用户名\Documents\Virtual Machines\Ubuntu 20.04\vmware.log
用记事本直接打开，Ctrl+F搜索几个关键线索，比如“panic”“fault”“vcpu-0”“MonitorLoop”和“failed”。崩溃发生时，日志最后几十行通常会留下一个错误描述，比如“vcpu-0: inconsistency detected”或“The guest OS has attempted to execute an instruction that is not allowed”。这些描述用搜索引擎一查，往往能找到对应官方知识库，比自己翻设置高效得多。
6.2 Ubuntu系统内的 dmesg 与 journalctl
如果虚拟机没彻底崩死，还能进系统或恢复模式，就能直接在Ubuntu里拿到日志。dmesg是内核环缓冲，记录着内核启动以来的变量信息，可以用来查硬件相关错误：
bash复制dmesg -T | grep -iE 'error|panic|fail|stuck'
journalctl是systemd生成日志的入口，查看上一次启动到崩溃前的最后输出：
bash复制journalctl -b -1 -e
-b -1表示上一次启动会话，-e直接从尾部开始看，崩溃前最后一行往往隐藏着真正的死因，比如某个驱动模块加载失败、某个PCI设备地址冲突。找到具体报错后再搜索，比笼统地搜“Ubuntu崩溃怎么解决”有用得多。
6.3 崩溃前后的行为对比：一次只动一个变量
最后分享一个排查心态：遇到崩溃，不要同时去改虚拟机内存、升级VMware版本、换GRUB参数、装驱动，这样即使系统好起来了，你也不知道是哪一步救了你。正确做法是每次只改变一个变量，记录结果，变量不同再试下一个。比如先加nomodeset，没见过明确结果前不要去动3D加速，这样每个方案都能被验证，后续再遇到崩溃也有一套稳定的回退链。
7. 从崩溃现场到稳定运行的最后一公里
写完这么多，看起来步骤很多，但实际执行时，大部分崩溃场景只需要两三个方案就能落地。我自己的习惯是：新建Ubuntu 20.04虚拟机时，客户机类型设置成Ubuntu 64位、内存给4GB、虚拟化引擎勾选VT-x/AMD-V、磁盘用NVMe、关闭3D加速；安装时在GRUB加入nomodeset；进系统后第一时间安装open-vm-tools-desktop，再创建一个干净快照。这套流程下来，崩溃率极低，后面不管怎么折腾都有一个可回退的稳定点。
如果你已经装到一半崩溃了，别急着删虚拟机重来，先按第1章判断现象类型，再顺着第2章到第4章的排查链路去试。记住一个原则：宿主机和虚拟化层的冲突要通过BIOS和VMware设置解决，系统内部的显示问题要通过内核参数和VMware Tools解决，驱动加载冲突要通过禁用不必要的硬件加速解决。大多数崩溃走到这三步就能定位出来。
我在实际排查中还发现，很多“崩溃”其实是被放大了的假象——宿主机内存不足造成的卡顿被当成崩溃，ISO损坏引导安装失败被当成崩溃，Hyper-V冲突导致VMware窗口闪退也被当成崩溃。真正把每条链路过完，你会发现Ubuntu 20.04在VMware里完全可以稳定运行，只是安装前那几分钟的慎重配置，换来的是后面几个月省心。希望这篇排错记录能帮你少走几条弯路，把时间省下来用在实际要做的事情上。