企业官网建设流程全解析

说起 Ubuntu 安装和启动时的花屏问题，我估计不少用 NVIDIA 显卡的朋友都经历过那种“装机半小时，折腾一整天”的崩溃感。明明 Windows 下好好的，一到 Ubuntu 安装界面就满屏雪花、色块乱飞，运气好能靠盲打命令继续，运气不好直接卡死在引导阶段。这个坑我在 2020 年帮人装系统时反复踩过，前后在 Ubuntu 18.04 和 20.04 上验证了多套方案，今天把我实测有效的排查思路和操作步骤完整梳理出来，希望给还在被花屏折磨的朋友一条清晰的路。

这篇文章不是什么高深理论，就是一套从“应急能开机”到“彻底用上显卡”的完整流程，包括临时启动参数、系统配置修改、NVIDIA 官方驱动安装和常见报错排雷。不管你是双系统新手、实验室装机的老手，还是被深度学习环境逼着切换系统的研究人员，只要遇到和 NVIDIA 花屏、驱动加载失败相关的问题，这篇内容都值得你花五分钟看完并收藏备用。

1. 问题现象与根源分析

1.1 典型的三种花屏场景

NVIDIA 显卡在 Ubuntu 下的花屏问题，其实不是单一故障，而是几个不同阶段的症状集合。我根据自己遇到过的情况，把最典型的场景分为三类，方便大家对号入座，判断自己卡在哪一步：

第一种是系统安装阶段就花屏。U 盘启动进入 GRUB 引导菜单，还没看到 Ubuntu 的安装界面，屏幕就开始出现杂色条纹、乱码或者直接黑屏。这种情况常见于较新的 Turing、Volta 架构显卡，比如 RTX 20 系、部分 GTX 16 系，在安装盘加载内核时就已经出问题了。

第二种是系统安装完成后第一次重启花屏。安装过程一切正常，甚至分区、配置都能顺利进行，但重启后进入系统加载界面时就花了。这个阶段最让人抓狂，因为系统是装好的，但你就是看不到桌面，容易误判为“系统没装好”而反复重装，白白浪费大量时间。

第三种更隐蔽，是安装完 NVIDIA 官方驱动后，开机进入登录界面或桌面后才花屏，或者表现为整体系统能运行，但某个应用、某类游戏一打开就花屏闪退。这个就涉及驱动版本不匹配、内核模块冲突、Xorg 配置残留等问题，定位起来比前两种更费神。

我自己见过最夸张的一个案例，是一台 RTX 2070 的笔记本，前两种花屏问题同时出现，安装时必须加启动参数才能进入 LiveCD，装完系统后还必须用 recovery 模式修改 GRUB 配置，否则永远到不了登录界面。可以说，只要涉及安装和启动，就处处是坑。

1.2 花屏的真正元凶：nouveau 驱动

在深入解决方案之前，有必要把这个问题的根源说透。Ubuntu 之所以在 NVIDIA 显卡上频繁花屏，核心原因在于系统默认加载的是开源驱动 nouveau，而不是 NVIDIA 官方闭源驱动。

nouveau 是 Linux 社区通过逆向工程开发的开源驱动，它最大的价值是让 NVIDIA 显卡在 Linux 下“能用”，比如你只做基本的办公、看网页，它勉强可以胜任。但这就像用一把借来的螺丝刀去拆一台精密仪器——它能拧动螺丝，但契合度、精度、扭矩都远不如原厂工具。nouveau 对较新的 NVIDIA 显卡支持相当有限，尤其是在内核模式设置（KMS，Kernel Mode Setting）和高分辨率输输出上，经常出现显存管理、显示输出方面的缺陷，直接结果就是花屏、冻屏甚至彻底黑屏。

而 Ubuntu 从很早的版本开始，安装镜像默认就开启了 nouveau 的 KMS 功能。为什么要开 KMS？因为内核需要在图形界面启动之前，就接管显示输出、设置合适的分辨率，这样从内核启动到桌面环境出现的过渡才能流畅。听起来很美好，但 nouveau 的 KMS 实现并不完善，在切换分辨率、初始化某些显卡的视频 BIOS（VBIOS）时，就容易把画面“搞花”。这就像是在灯光忽明忽暗的舞台上做精细演出，演员动作没变，但观众看到的就是一卡一顿的残影。

理解了这一点，整个解决方案的思路就清晰了：既然问题出在 nouveau 驱动上，那就想办法绕开它，让系统在安装和启动阶段不要加载这个不可靠的开源驱动，等系统稳定运行后再安装 NVIDIA 官方驱动来接管显卡。

你可能会问，为什么 Ubuntu 不直接默认加载 NVIDIA 官方驱动？原因很复杂，涉及授权协议、系统安装包体积、内核更新兼容性等多方面考量。简单来说，官方驱动是闭源的，Ubuntu 无法很好地把它集成到默认的内核和安装流程中。所以“默认 nouveau，用户手动安装官方驱动”就成了一个约定俗成的方案，也因此才有了一代代 Linux 用户与花屏问题斗智斗勇的故事。

2. 安装阶段的应急方案：GRUB 临时参数

2.1 用 nomodeset 参数顺利进入安装界面

解决安装阶段花屏的核心思路就一个词：禁用 KMS。而实现这一目标最简单暴力的参数就是nomodeset。它的作用非常直接：不让内核在启动早期自动加载显卡驱动并设置显示模式，而是交给后续的初始化脚本来处理显示。

具体操作步骤如下。当你用启动 U 盘引导后，会看到 GRUB 菜单，上面有 “Try Ubuntu”、“Install Ubuntu” 等几个选项。此时不要直接按回车，先选中 “Try Ubuntu” 这一行，按键盘上的e键进入编辑模式。你会看到一大段启动参数文本，包含了内核启动时的各种配置。

在这段文本中，找到以linux开头的那一行，这行参数比较长，通常会包含quiet splash两个关键词。把光标移动到这行文字的末尾，敲一个空格，然后手动输入nomodeset。确认无误后，按Ctrl+X或者F10保存并启动。这时你会发现，之前的花屏问题消失了，系统可以正常进入安装界面。

之所以用nomodeset而不是其他参数，是因为它适用范围最广、兼容性最好。它在启动时告诉内核，不要尝试加载任何显卡驱动来设置显示模式，相当于一个“显示降级”的兜底方案。虽然这样进入系统后画面分辨率可能会比较低（比如 1024x768），图形加速能力也暂时不可用，但至少能保证你顺利走完安装流程。

2.2 更精准的补充参数与使用场景

除了nomodeset这个通用参数，我在不同版本和不同显卡上还试过其他组合，这里给你们提一嘴，以备不时之需。

如果你知道自己的显卡是 NVIDIA，而且确定问题的根源就是 nouveau 驱动的 KMS，那么在安装阶段可以直接用nouveau.modeset=0这个参数，效果比nomodeset更精准。它专门告诉内核不要加载 nouveau 驱动的模式设置功能，而其他内核模块（比如声卡、网卡等）的启动流程不受影响，整体启动速度和稳定性会更好。

还有些笔记本用户可能会遇到更诡异的情况：加装了nomodeset后花屏问题解决了，但触控板失灵、无线网卡不稳定。这种时候，可以尝试加acpi_osi=linux参数。这个参数的作用是让内核以更严格的方式处理 ACPI 表，一些笔记本厂商在 ACPI 表中加入了 Windows 特有的判断逻辑，可能导致 Linux 下的电源管理和设备初始化异常，加上这个参数后会强制走 Linux 的 ACPI 路径。

另外，如果你用的是双显卡笔记本（Intel 集成显卡 + NVIDIA 独显），安装时花屏可能来自 Optimus 切换机制的初始化解不上。这种情况可以尝试在启动参数中加入nomodeset的基础上，再添加acpi_backlight=vendor或者video.use_native_backlight=1，前者让系统使用厂商提供的背光控制方案，后者强制使用原生背光控制，两者都能缓解一些笔记本上的屏幕闪屏或亮度调节失效问题。

不过提醒一句，这些补充参数属于“按需使用”的范畴。正常情况下nomodeset就能解决 90% 以上的安装花屏问题，遇到特殊机型再逐项排查添加，不要一上来就各种参数堆叠。否则可能确实解决了花屏，但引入了新的系统异常，排查起来反而更痛苦。我自己的习惯是：先用nomodeset，若失败，再追加nouveau.modeset=0，再不行才考虑 ACPI 和背光参数。

3. 系统启动花屏的持久化修复

3.1 修改 GRUB 配置，让参数生效到每次开机

如果你靠临时参数装好了系统，但重启用后依然花屏，那就说明你需要在系统的 GRUB 配置中永久加入启动参数。否则每次开机，系统还是默认加载 nouveau 驱动，还是老样子花给你看。

首先正常进入刚装好的 Ubuntu 系统（如果又碰到了花屏，就用安装 U 盘里的 “Try Ubuntu”，挂载好系统分区后 chroot 进去改配置），打开终端，运行下面的命令修改 GRUB 配置文件：

sudo nano /etc/default/grub

找到GRUB_CMDLINE_LINUX_DEFAULT这一行，默认状态下它通常是：

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

把它修改为：

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"

如果你的系统在安装阶段还需要其他参数（比如nouveau.modeset=0），也一并加到这对引号里面，各个参数之间用空格隔开。不需要加在GRUB_CMDLINE_LINUX这个不带 DEFAULT 的变量里，那个变量主要用于 recovery 模式等场景，平时用 DEFAULT 就够了。

修改并保存后，执行一条命令让 GRUB 配置生效：

sudo update-grub

这条命令会自动扫描系统里的内核，重新生成/boot/grub/grub.cfg文件，把我们刚才添加的参数写进去。执行完毕后，重启系统，正常情况下你的 Ubuntu 不会再花屏了。

这里有个小细节值得注意：我遇到过不少朋友改了grub.cfg文件本身（比如直接编辑/boot/grub/grub.cfg），系统也生效了，但等内核更新后，参数又被默认配置覆盖了。正确做法是无论如何只改/etc/default/grub，然后跑update-grub。因为系统内核更新时，会自动通过update-grub重新生成grub.cfg，/etc/default/grub才是参数源头。

3.2 确认 nouveau 是否还在加载

重启进入系统后，不要急着开始下一步，先确认一下 nouveau 驱动的状态。毕竟加参数只是“让它不要做 KMS”，但 nouveau 模块仍可能被加载。你可以用下面这条命令检查：

lsmod | grep nouveau

如果返回了模块信息，说明 nouveau 还在系统里挂着。这种情况在nomodeset参数下一般不影响正常使用，也不会花屏，但如果你想安装 NVIDIA 官方驱动，就必须在下一步把 nouveau 彻底禁用掉。如果你执行后没有任何输出，说明 nouveau 模块没有被加载，这个状态对后续安装驱动非常有利。

同时，你也可以用下面这组命令看看当前显卡的软硬件信息，结合判断一下显卡到底处于什么状态：

lspci | grep -i nvidia

以及查看当前系统实际用的是哪个显示驱动：

ls -l /sys/class/video4linux/video0 2>/dev/null; glxinfo | grep "OpenGL renderer"

当然，如果还没安装mesa-utils，glxinfo命令会提示找不到。可以先用sudo apt install mesa-utils装上，再查看。这个命令输出的 “OpenGL renderer” 一行，能直观告诉你系统目前是通过什么驱动来渲染图形——如果显示的是llvmpipe，说明当前没有硬件加速，而是 CPU 软渲染，这是花屏问题未完全解决或驱动未正确安装时的典型状态。

4. 彻底解决：安装 NVIDIA 官方驱动

4.1 禁用 nouveau 并重新生成 initramfs

通过启动参数的临时方案，我们只是暂时绕开了 nouveau 的花屏问题，但系统的显示性能依然处于“能用但不好用”的状态。为彻底解决，也为了让显卡能在 Ubuntu 下发挥完整性能（特别是需要用 CUDA、cuDNN 做深度学习的同学），我们接下来安装 NVIDIA 官方闭源驱动。

安装官方驱动的第一步，是把 nouveau 彻底拉黑。创建一个黑名单配置文件：

sudo bash -c "echo 'blacklist nouveau' >> /etc/modprobe.d/blacklist-nouveau.conf" sudo bash -c "echo 'options nouveau modeset=0' >> /etc/modprobe.d/blacklist-nouveau.conf"

这个文件的作用，是在系统启动加载模块时直接跳过 nouveau，让它没有机会加载到内核中。黑名单中两行内容含义不同：blacklist nouveau是禁止模块加载；options nouveau modeset=0是即使模块被其他东西强行拉起来，也不让它开启 KMS。双管齐下，避免意外。

保存后，重新生成 initramfs，让这个配置打进启动镜像里：

sudo update-initramfs -u

这一步非常关键，许多人禁用 nouveau 后重启又遇到花屏或卡死，就是因为忘记重新生成 initramfs。initramfs 是内核启动早期阶段的一个微型根文件系统，包含了加载真正根文件系统所需的驱动和模块。只有重新打包它，黑名单配置才会在内核启动的最早期就生效。执行完这条命令后，建议重启系统一次，确认不再花屏、系统正常进入。如果重启后一切正常，再进入下一步安装驱动。

4.2 安装 NVIDIA 驱动的三种方式对比

安装 NVIDIA 官方驱动常见有三种方式：apt 直接安装、PPA 源安装、官网 runfile 安装。这三条路的适用场景和坑点各有不同，我实际操作中也都踩过，下面从左到右简单对比一下：

第一是 Ubuntu 官方源直接安装。这个方法最简单，直接在终端执行sudo apt install nvidia-driver-XXX，系统会自动从官方仓库下载并安装。优点是省心、不需要添加额外源，稳定性也比较好；缺点也很明显：版本往往偏旧。Ubuntu 的发版策略和内核一样偏保守，官方源里的驱动版本可能比你需要的落后不少，如果你是刚入手新显卡，很可能官方源里根本没有适合的版本。

第二是使用 graphics-drivers PPA。这是目前推荐度最高、也是我装机时最常用的方式。PPA（Personal Package Archive）是 Ubuntu 社区维护的软件仓库，graphics-drivers 这个 PPA 专门维护 NVIDIA 最新的稳定版和候选版驱动。相比官方源，它能拿到更新的驱动版本，而且依然是 deb 包，安装和卸载都方便，不会像 runfile 那样把系统文件搞乱。唯一的注意点是，PPA 是社区维护的，虽然可靠性已经经过大量用户验证，但理论上仍存在极低的与系统不兼容的风险。

第三是官网 runfile 安装。这种方法灵活性和控制力最高，你可以精确下载某个版本号的驱动，比如 CUDA 10.2 对应 440.44，CUDA 11.0 对应 450.80。但缺点同样明显：手动编译内核模块、手动管理 Xorg 配置，操作步骤多且容易出问题，比如内核更新后驱动模块失效，需要重新编译，对新手不太友好。我在为服务器安装驱动时偶尔会用它，个人机的建议还是优先走 PPA。

为方便对比，我把三种方式的优劣整理成一个表：

4.3 PPA 方式的具体操作流程

以我自己用的 PPA 方式为例，完整流程如下。

先添加 graphics-drivers 的 PPA 源并更新软件包信息：

sudo add-apt-repository ppa:graphics-drivers/ppa sudo apt update

添加完 PPA 后，可以用下面这条命令查看系统推荐安装哪个版本的 NVIDIA 驱动，以及列出版本选择和硬件推荐情况：

ubuntu-drivers devices

执行后，你会看到类似这样的输出：

== /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0 == modalias : pci:v000010DEd00001E87sv00001028sd0000118Bbc03sc00i00 vendor : NVIDIA Corporation model : TU104 [GeForce RTX 2080] driver : nvidia-driver-440 - third-party free recommended driver : nvidia-driver-435 - third-party free driver : nvidia-driver-390 - third-party free driver : xserver-xorg-video-nouveau - distro free builtin

系统会直接给出推荐的驱动版本。一般来说，直接安装 recommended 那个版本即可。命令格式是：

sudo apt install nvidia-driver-440

如果你的 output 里没有显示 recommended，或者“driver”行是空的，说明 PPA 源可能没有识别到显卡型号。这种情况我也遇到过，多见于较新的显卡配旧版 PPA 源。解决办法是更新 PPA 源后重新运行ubuntu-drivers devices，或者直接用sudo apt search nvidia-driver查看 PPA 里有哪些可用版本，然后手动指定一个适合你显卡的版本安装。

驱动安装完成并且系统重启后，用nvidia-smi验证驱动是否正常。正常运行会输出 GPU 型号、驱动版本、显存占用等详细信息。同时建议运行nvidia-settings查看 NVIDIA 控制面板，确认驱动已经完整接管显卡。

4.4 安装驱动的常见坑位提醒

虽然 PPA 方式已经很省心，但有几个坑是很多人反复踩的。

第一个坑是 Secure Boot 未关闭。现代主板默认开启 UEFI 安全启动（Secure Boot），Ubuntu 内核为了保证启动链的安全性，只加载有合法签名的模块。NVIDIA 闭源驱动的内核模块默认没有签名，如果 Secure Boot 开启状态，系统启动后你会发现nvidia-smi报错，提示无法与驱动通信，根本原因就是模块被安全策略拦住了。解决方法有两个：要么进 BIOS 关闭 Secure Boot（最简单直接），要么在 Ubuntu 中注册 MOK（Machine Owner Key，机器所有者密钥）并给驱动模块签名，后者流程相对繁琐，个人用户建议直接关掉 Secure Boot。

第二个坑是内核头文件缺失。编译 NVIDIA 驱动模块时需要linux-headers-$(uname -r)，如果系统没有安装，驱动安装过程可能报错。虽然 PPA 方式会自动处理依赖，但保险起见，我还是建议先执行：

sudo apt install linux-headers-$(uname -r) sudo apt install dkms build-essential

dkms（Dynamic Kernel Module Support）非常重要，它能让驱动在系统内核更新后自动重新编译模块，省去每次内核升级都要手动装驱动的麻烦。如果你后续遇到内核更新后nvidia-smi又失效的问题，大概率就是没有安装 dkms 或者 dkms 状态异常。

第三个坑是旧驱动残留。如果你之前用过 apt 方式装过 NVIDIA 驱动，或者尝试过 runfile 安装，再切换到 PPA 方式时，系统里可能残留了旧版本的内核模块和 Xorg 配置。这种残留会导致新驱动行为诡异，比如开机卡在登录界面循环、桌面环境分辨率异常。处理方法是彻底清理：

sudo apt purge nvidia-* sudo apt autoremove

清理完成后需要重启系统，再开始安装新驱动。虽然 purge 命令看着有点吓人，但装驱动这件事，干净的环境永远比“部分更新”的状态可靠。

5. 常见问题与排查技巧实录

5.1 nvidia-smi 报错：couldn't communicate with the NVIDIA driver

这个应该是酷炫度最高的报错之一，也是装驱动后最常见的状况。终端执行nvidia-smi，结果是：

NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.

看到这个报错，不要慌，它说明你在用户态能看到驱动包，但内核态的驱动模块没有正常工作。排查方向按下面几步走。

第一，检查模块是否正常加载：

lsmod | grep nvidia

如果输出为空或者只有几个没有关联到nvidia的残留模块，说明驱动模块是在启动时被拒了或没有编译成功。查看内核日志来定位原因：

dmesg | grep -i nvidia

如果看到类似 “module verification failed: signature not found” 或 “Unknown symbol” 的信息，那就对应上前面说的 Secure Boot 或内核头文件版本不匹配的问题，回到上一节处理。

第二，确认你当前用的内核和驱动模块版本是否匹配。特别是内核更新后，如果你没装 dkms，驱动模块库还是旧内核的。这种情况下，ls /usr/lib/modules/$(uname -r)/updates/dkms/这个目录大概率是空的或不存在。解决办法就是重新触发一次模块构建：

sudo dpkg-reconfigure nvidia-dkms-440

把 440 换成你实际安装的驱动版本号即可。如果提示找不到包，就用dpkg -l | grep nvidia查看具体包名。

第三，如果你用的是库依赖方式（比如通过 conda、venv 安装的 PyTorch 或 TensorFlow），还需要确认/usr/lib/x86_64-linux-gnu/libcuda.so和/usr/lib/x86_64-linux-gnu/libnvidia-ml.so等链接是否存在或有正确的符号连接。有些精简安装过程会把这些链接弄丢，导致 CUDA 运行时能装上但找不到驱动库。可以用sudo ldconfig刷新动态链接库缓存后再试。

5.2 Xorg 报错：failed to load module "glxserver_nvidia"

还有一个我遇到过的比较难缠的报错，出现在系统启动日志里：

(EE) NVIDIA: Failed to load module "glxserver_nvidia" (module does not exist, 0)

这个报错看上去像是驱动缺失，但实际上多数时候是驱动安装时 Xorg 的配置残留问题。Xorg 启动时会在/etc/X11/xorg.conf或/usr/share/X11/xorg.conf.d/下找显卡相关的配置文件，如果你之前用 runfile 安装过驱动，它会生成一个包含glxserver_nvidia模块的行，但后来换成了 PPA 方式，旧的配置文件还在，新驱动路径又对不上，于是悲剧发生。

处理方法也很直接：找到并删除这些残留的 Xorg 配置片段，然后重启系统。通常重点关注下面这两个路径：

sudo rm -f /etc/X11/xorg.conf sudo rm -f /etc/X11/xorg.conf.d/*nvidia*

删除后重启，Xorg 会自动重新探测显卡并生成合适的配置。需要注意别手误删到其他重要的配置片段（比如触控板、显示器配置），可以先备份一份再删。

如果重启后还是没有恢复，可以手动跑一下 Xorg 的配置探测：

sudo nvidia-xconfig

这条命令会扫描当前显卡和显示器信息，生成一份新的/etc/X11/xorg.conf，并把 NVIDIA 驱动作为首选渲染设备。这个方法在简单场景下很有效，但如果你用的是较新的桌面环境（如 GNOME 3 默认的 Wayland 会话），可能反而会引入新的兼容问题。所以我个人的建议是：先手动检查清理残留，尽量不主动生成 xorg.conf，让系统自动管理更省心。

5.3 VMware 虚拟机安装 Ubuntu 后的花屏补充说明

很多朋友问过我：VMware 虚拟机里装 Ubuntu 也花屏，和实体机是一个问题吗？答案是不完全一样。虚拟机里通常没有 NVIDIA 显卡直通（除非配置了 VFIO 直通或 VMware 的 vGPU 功能），它用的是 VMware 自研的虚拟显卡，比如 vmwprog、vmvga 等。虚拟机花屏更多是 VMware Tools 未安装、显示内存配置太小，或 3D 加速未开启导致的。

解决思路和前面完全不同。优先在 VM 设置中给虚拟机分配较大的显存（比如 128MB 或 256MB），开启 “Accelerate 3D graphics” 选项，进入系统后安装 open-vm-tools：

sudo apt install open-vm-tools open-vm-tools-desktop

安装完成后重启虚拟机，花屏问题基本能解决。在虚拟机里不要安装 NVIDIA 官方 Linux 驱动，因为虚拟显卡本来就不是 NVIDIA 硬件，强行装驱动反而可能适得其反。

5.4 一个容易忽视的方向：显存与温度导致的“递延式”花屏

最后说一个容易被忽视的方向。如果你的 Ubuntu 系统日常使用一直很稳定，玩普通游戏也没问题，但一跑重型负载（比如虚幻引擎开发的游戏或 CUDA 训练）就出现花屏或闪退，这时候考虑的就不再是驱动问题了，而是硬件状态。

我遇到过最典型的情况是显卡显存过热或供电不稳定导致的“递延式”花屏。现象很迷惑：日常办公、看视频流畅无碍，因为负载低，显存频率不高；一旦跑 3D 场景或 CUDA 计算，显存频率拉到高位，温度直冲 80 度以上，焊接不良或老化了的显存颗粒就会出错，反映在画面上就是花屏、闪退，严重时甚至直接系统重启。

排查这种问题，先用nvidia-smi加个轮询命令观察温度和功耗：

watch -n 1 nvidia-smi

如果发现温度在 85 度以上才出现花屏，那大概率是散热问题。清理灰尘、更换硅脂、增强机箱风道都是方向。显存频率不稳还有一种情况是驱动层面的功耗管理策略异常，可以尝试关闭显卡的持久模式：

sudo nvidia-smi -pm 1

以及在 NVIDIA X Server 设置中把 “PowerMizer” 设置为 “Prefer Maximum Performance”。虽然这会增加待机功耗，但能减少因驱动自动降频带来的显存不稳定问题。

在排查这类疑难问题时，我个人的建议是：先软后硬。先用排除法验证驱动版本、内核模块和 Xorg 配置是否干净，再考虑刷 VBIOS、改散热这些硬件层面的操作。毕竟软件层面的修复成本低、风险小，而硬件改动一旦失手，可能直接让显卡告别世界。

这个方向虽然不属于安装阶段的花屏问题，但既然很多朋友最后都会进入“装好驱动 → 玩游戏/跑训练 → 花屏”这个流程，在这里一并写出来，省得你们走弯路。