Ubuntu 24.04 LTS 装机、开发部署与故障排查实战

Ubuntu 是目前桌面和服务器两端都能打的 Linux 发行版之一。它不像某些发行版那样需要大量手工配置才能用起来，也不像商业系统那样把一堆能力锁在授权后面。对大多数开发者来说，Ubuntu 的价值很直接：装上就能写代码，装上就能跑服务，装上就能接 Docker、接 GPU 驱动、接各种开源工具链。这篇文章不聊发行版之争，只讲一条完整链路——从镜像下载、启动盘制作、安装分区，到换源、开发环境搭建、服务部署、资源观察和故障排查，把“装完不会用”这个最常见的坑填掉。

这次的内容以 Ubuntu 24.04 LTS 为主线，同时标注 22.04 LTS 的差异点，因为这两个版本目前是主力。核心特点可以先给出来：第一，LTS 版本提供长期安全更新，适合长期跑的生产和学习环境；第二，apt 包管理加 snap 生态，常用软件基本一条命令解决；第三，桌面版和服务器版共用同一套底层，本地调好的脚本可以直接搬到服务器；第四，对 NVIDIA 显卡、CUDA、Docker、KVM 虚拟化支持成熟，是做 AI 和云原生最省心的底座之一；第五，社区资料量极大，遇到报错基本能搜到答案。

本文会带读者完成这些事：准备安装介质并校验完整性、在物理机和虚拟机两条路径上完成安装、做系统初始化（换源、时区、SSH、常用工具）、搭一套 Python/Node/Docker 开发环境、用 Nginx 加 systemd 部署一个真实服务、观察 CPU 内存磁盘和 GPU 的占用情况、最后用一张排查表覆盖装机过程中最常撞见的十几类问题。适合刚接触 Linux 的开发者、需要本地搭实验环境的学生、要给团队做标准化镜像的运维，以及想把手上的旧笔记本改造成家庭服务器的用户。

需要提前说明一点：Ubuntu 的安装过程本身很稳定，真正让人卡住的往往不是安装，而是装完之后的引导、驱动、源、权限和网络。所以本文的篇幅会向“安装后的半小时”倾斜，那半小时决定了你这套系统是能用还是能用得舒服。

1. Ubuntu 核心能力与版本速览

Ubuntu 的版本号规则是“年份.月份”，每两年一次的 4 月版本是 LTS（长期支持），普通版本只维护 9 个月，LTS 版本标准支持 5 年，涉及基础设施的组件可以通过 Ubuntu Pro 延长。这个规则决定了选型逻辑：学习、开发、生产一律优先 LTS，尝鲜才考虑中间版本。24.04 LTS 是当前主线，22.04 LTS 仍然大量存在于企业环境中，20.04 LTS 已进入维护后期，新项目不建议再作为首选。

从上表能看出来，Ubuntu 的定位不是“最小化”，而是“开箱可用”。代价是默认安装会带上不少你可能用不到的服务，比如 snapd、云初始化组件、打印服务等。对绝大多数人这不是问题，但对追求极致精简的嵌入式或容器基础镜像场景，Debian、Alpine 会更合适。判断标准很简单：你要的是“一台能干活的机器”，选 Ubuntu；你要的是“一个 20MB 的运行时”，别选它。

还有一个容易被忽略的差异点：桌面版和服务器版的安装器现在都基于 Subiquity 体系，界面流程接近，但服务器版默认不装图形界面，装完之后只有命令行。这不是缺陷，是设计取向——服务器版把资源全留给业务进程。如果你的机器只有 2GB 内存，装服务器版再按需手动装轻量桌面，比直接装桌面版流畅得多。

2. 适用场景与使用边界

Ubuntu 最适合三类人。第一类是应用开发者，需要一套和线上环境接近的本地系统，Python、Node、Java、Go 的运行时在 apt 里都有，Docker 一条命令装好，不用折腾依赖地狱。第二类是算法和 AI 方向的从业者，NVIDIA 官方驱动在 Ubuntu 仓库里维护得比较及时，CUDA、cuDNN、PyTorch 的安装文档也基本以 Ubuntu 为默认示例，踩坑成本最低。第三类是想把旧硬件利用起来的用户，一台 8GB 内存的老笔记本装上 Ubuntu 服务器版，跑个文件服务、下载机、内网面板、小型数据库都够用。

但有些场景要慎重。生产环境如果要求商业级 SLA 和技术支持响应，需要评估 Ubuntu Pro 或转向有商业支持的发行版，不要指望社区论坛兜底。涉及等保、审计、合规要求的系统，装机前要确认基线加固方案、日志留存策略和责任划分，默认安装肯定不满足。超低配设备（1GB 内存以下、老旧的 32 位 CPU）不适合现代 Ubuntu 桌面版，考虑轻量发行版更现实。需要长期固定内核版本、不允许随意升级的场景，要提前锁定内核和包版本，否则一次 apt upgrade 就可能把驱动搞挂。

合规和边界方面有三点必须强调。第一，本文所有命令仅用于自己拥有或已获授权的设备，不要对他人系统做未授权操作。第二，涉及数据采集、日志留存、用户信息处理的部署，必须遵守相关法律法规和内部制度，敏感数据要脱敏、加密、限制访问范围。第三，安装第三方驱动、闭源软件、非官方源之前，要确认来源可信，不要随便执行网上抄来的 curl | bash，那等于把 root 权限直接交出去。

另外提醒一句，很多人装 Ubuntu 是为了跑 AI 模型。这类用途要注意模型授权、训练数据来源合法性、生成内容的合规使用。本地部署不等于没有责任，输出内容仍然要经过审核，涉及人像、声音、版权的素材必须有明确授权。

3. 安装前的环境准备

3.1 硬件与固件检查

装机前先确认三件事：CPU 架构、内存容量、磁盘可用空间。现在的镜像分 amd64（x86_64）和 arm64 两大类，下载错了直接无法引导。内存方面，桌面版低于 4GB 会明显卡顿，8GB 是比较舒服的起点；服务器版 1GB 能跑起来，但要跑数据库和容器建议 4GB 起。磁盘至少留 25GB 给桌面版，服务器版 10GB 起步，实际部署建议 40GB 以上，因为 Docker 镜像和日志增长很快。

固件层面要确认两点：是不是 UEFI 引导、安全启动（Secure Boot）是否开启。UEFI 加 GPT 分区是现代默认组合，如果机器是 Legacy BIOS，安装时要注意引导分区的位置。Secure Boot 开启时，部分第三方驱动（尤其是 NVIDIA 闭源驱动）需要签名或手动处理，新手建议先在 BIOS 里关掉，装完再决定是否打开。

顺手记录一下硬件信息，后面装驱动会用到。无线网卡型号、显卡型号、有线网卡芯片，这三样是装机后最容易出问题的部件。Windows 下可以在设备管理器里看，或者用一条命令导出：

powershell复制# Windows 下导出主要硬件信息，便于装完 Ubuntu 后对照
Get-CimInstance Win32_NetworkAdapter | Where-Object {$_.NetEnabled -eq $true} | Select-Object Name, MACAddress
Get-CimInstance Win32_VideoController | Select-Object Name, DriverVersion

3.2 镜像获取与完整性校验

镜像只从官方或官方认可的镜像站下载。国内访问官方站点速度可能一般，可以改用高校或云厂商的镜像站，但一定要核对校验值，不要用来路不明的“优化版”“精简版”镜像——这类镜像被塞进后门的案例不少。

下载完成后先做 SHA256 校验。Windows 下用 PowerShell：

powershell复制# 计算镜像哈希，与官方 SHA256SUMS 文件中的值逐位比对
Get-FileHash .\ubuntu-24.04-desktop-amd64.iso -Algorithm SHA256

Linux 或 macOS 下：

bash复制# 计算并比对哈希，输出一致才说明文件完整未被篡改
sha256sum ubuntu-24.04-desktop-amd64.iso

校验不通过就重新下载，不要抱着“应该没事”的心态继续。写到 U 盘的过程中如果出现坏块，装到一半报 I/O 错误，排查起来非常浪费时间。

3.3 启动盘制作

Windows 下常用 Rufus，跨平台可以用 balenaEtcher，两者都是图形界面，选择镜像、选择 U 盘、点开始即可。Rufus 会问用 ISO 模式还是 DD 模式，Ubuntu 官方镜像两种都能用，遇到引导异常时换 DD 模式重写一次往往能解决。

Linux 下可以直接用 dd，速度快但要小心设备名。写错设备名会直接抹掉你的硬盘数据：

bash复制# 先确认 U 盘设备名，务必核对容量和型号再执行下一步
lsblk -o NAME,SIZE,MODEL,TRAN

# 卸载已挂载的分区，然后整盘写入，of 后面的设备名必须替换成你的 U 盘
sudo umount /dev/sdX* 2>/dev/null
sudo dd if=ubuntu-24.04-desktop-amd64.iso of=/dev/sdX bs=4M status=progress oflag=sync
sync

oflag=sync 让写入同步落盘，避免拔盘时数据没写完。写完执行 sync 再拔。整个过程几分钟到十几分钟，取决于 U 盘写入速度。

3.4 虚拟机方案

不想动本机分区，可以先在虚拟机里跑一遍熟悉流程。VirtualBox、VMware Workstation Player、Hyper-V 都能装，配置上给 4GB 内存、2 核 CPU、40GB 动态磁盘就够练习。虚拟机的好处是快照随便打，装崩了回滚即可；缺点是 GPU 直通麻烦，做 AI 训练基本不可行，显卡加速需要额外配置。

Windows 用户还有一条更轻的路径：WSL2。它不是完整虚拟机，而是和 Windows 深度集成的 Linux 子系统，适合跑命令行工具、编译、脚本，不适合跑 systemd 服务和完整桌面：

powershell复制# 安装 WSL2 并指定 Ubuntu 版本，装完按提示设置用户名密码
wsl --install -d Ubuntu-24.04
wsl --set-default-version 2
wsl -l -v

WSL2 的坑在于文件系统性能：跨系统访问 /mnt/c 下的项目会非常慢，代码一定要放在 Linux 侧的家目录里。另外 WSL2 默认不开 systemd，需要在 /etc/wsl.conf 里显式开启，否则 systemctl 命令直接用不了。

3.5 磁盘分区规划

这是整个安装流程里唯一“做错要重来”的步骤，值得单独花十分钟想清楚。推荐方案如下：

把 /home 独立出来的好处很实际：将来重装系统或换发行版，只要不格式化 /home，个人配置和文档都还在。做 AI 的可以再加一块盘挂到 /data，模型文件动辄几十上百 GB，和系统盘分开管理能避免根分区被撑爆。

如果机器上已有 Windows，走双系统路线时先在 Windows 的磁盘管理里压缩出未分配空间，不要在 Ubuntu 安装器里直接压缩 NTFS 分区，风险高。压缩前记得备份，并且关掉 Windows 的快速启动和休眠，否则 NTFS 分区处于“未干净卸载”状态，Linux 侧挂载会失败。

4. Ubuntu 安装全流程实操

4.1 引导与安装器入口

插上 U 盘重启，进 BIOS 或快捷启动菜单（不同品牌按键不同，常见 F2、F12、Esc、Del），把 U 盘设为第一启动项。UEFI 机器建议用 UEFI 模式启动，Legacy 模式在双系统场景下容易和 Windows 的引导方式冲突。

进入 GRUB 菜单后选择“Try or Install Ubuntu”。如果卡在黑屏、花屏，或者进度条走一半不动，在 GRUB 界面按 e 编辑启动参数，在 linux 那一行末尾加上 nomodeset，再按 F10 启动。这是绕过显卡驱动问题最常用的手段，装完系统后再补装正确驱动即可。

4.2 安装向导关键选项

安装器的选项不算多，但有几个直接影响后续体验。语言建议选 English，因为中文界面下家目录会变成“下载”“桌面”这样的中文路径，很多命令行工具和脚本处理中文路径会出问题。时区选 Asia/Shanghai。键盘布局默认即可。

安装类型上，新手选“Erase disk and install Ubuntu”最省事，但会清空整块磁盘，务必确认选中的盘是对的。双系统选“Install Ubuntu alongside”，安装器会自动缩容，但成功率不如手动分区稳定，我更推荐选“Something else”手动指定。

“Install third-party software for graphics and Wi-Fi hardware”这个勾选项建议勾上，它会顺带装上无线网卡固件和显卡驱动，能省掉装完没网的尴尬。如果你的无线网卡型号较新，勾了也可能没驱动，那就先用有线网连接，装完再补。

4.3 手动分区操作

选“Something else”后，界面上会列出所有磁盘和分区。操作顺序是：先找到那块空闲空间，点“+”，依次创建 EFI 分区、swap、根分区、home 分区。EFI 分区必须是 FAT32，挂载点选 /boot/efi，大小 512MB 起；swap 分区类型选“swap area”；根分区类型 ext4，挂载点 /。

“Device for boot loader installation”这里要选对。纯 Ubuntu 单系统选整块磁盘（比如 /dev/nvme0n1）；双系统也是选整块磁盘而不是某个分区，安装器会自动把 Ubuntu 的引导项注册到已有的 EFI 分区里，不会覆盖 Windows 引导。选错的话装完可能进不去系统，需要用 Live USB 修复，比较折腾。

4.4 首次启动的检查清单

安装完成重启，拔掉 U 盘，正常应该进入登录界面。第一次进系统别急着装软件，先跑几条命令确认基础状态：

bash复制# 确认版本、内核、桌面环境
lsb_release -a
uname -r
echo $XDG_CURRENT_DESKTOP

# 确认磁盘挂载和剩余空间
df -hT

# 确认内存和 swap
free -h

# 确认显卡和网卡是否被正确识别
lspci | grep -Ei 'vga|3d|network'

重点看三个地方：df -hT 里 EFI 分区是不是挂在 /boot/efi，free -h 里 swap 是否有值，lspci 里显卡型号是否和实际硬件一致。如果显卡显示为 “VGA compatible controller: NVIDIA Corporation Device xxxx”，说明驱动还没装好，后面单独处理。

4.5 服务器版安装与网络配置

服务器版安装流程类似，差异在于没有图形界面，装完直接是命令行，并且网络用 netplan 管理。如果在安装时没配好静态 IP，可以手动改配置文件：

yaml复制# /etc/netplan/01-netcfg.yaml
# 注意：新版 Ubuntu 已弃用 gateway4 字段，改用 routes 声明默认网关
network:
  version: 2
  ethernets:
    ens33:
      dhcp4: false
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [223.5.5.5, 119.29.29.29]

写完执行 sudo netplan apply 生效。YAML 对缩进极其敏感，必须用空格不能用 Tab，缩进错了会直接报解析错误。改之前建议先 sudo cp 备份一份，改崩了能立刻还原。

5. 系统初始化配置

5.1 更换软件源

默认源在国外，国内下载速度可能只有几十 KB/s。换源是装完系统后第一件该做的事。24.04 使用的是新的 deb822 格式，文件在 /etc/apt/sources.list.d/ubuntu.sources；22.04 及更早使用的是 /etc/apt/sources.list 一行式格式。改之前先备份：

bash复制# 备份原配置，出问题可以立即还原
sudo cp /etc/apt/sources.list.d/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources.bak

24.04 的配置内容参考如下（以清华镜像为例，实际使用时按所在网络选择更快的镜像站）：

properties复制# /etc/apt/sources.list.d/ubuntu.sources
Types: deb
URIs: https://mirrors.tuna.tsinghua.edu.cn/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: https://mirrors.tuna.tsinghua.edu.cn/ubuntu/
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

22.04 的对应写法是：

bash复制# /etc/apt/sources.list，jammy 对应 22.04
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-updates main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-backports main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-security main restricted universe multiverse

改完执行更新。如果出现 Release file is not valid yet 或签名报错，多半是镜像站同步延迟或系统时间不对，先校准时间再重试：

bash复制sudo apt update
sudo apt upgrade -y

5.2 时区、主机名与基础工具

时间不对会导致 HTTPS 证书校验失败、日志时间错乱、apt 报签名错误，所以时区和时间同步必须配好：

bash复制# 设置时区并开启时间同步
sudo timedatectl set-timezone Asia/Shanghai
sudo timedatectl set-ntp true
timedatectl status

# 修改主机名，服务器上建议用有意义的名字
sudo hostnamectl set-hostname dev-node-01

再装一批日常必用的工具，这些基本是标配：

bash复制sudo apt install -y build-essential curl wget git vim htop net-tools \
  tree unzip zip ripgrep tmux jq ca-certificates gnupg lsb-release

build-essential 包含 gcc、g++、make，很多 Python 包和源码编译都依赖它，漏装会在编译阶段报 command 'gcc' not found，属于典型的新手卡点。

5.3 SSH 服务与远程访问

服务器版通常默认装了 openssh-server，桌面版需要手动装。装完确认服务状态和防火墙放行：

bash复制sudo apt install -y openssh-server
sudo systemctl enable --now ssh
sudo systemctl status ssh --no-pager

# 查看本机 IP，用于远程连接
ip -4 addr show | grep inet

远程登录更推荐用密钥而不是密码，安全性差别很大。本地生成密钥对后把公钥推上去：

bash复制# 本地执行，一路回车即可，生产环境建议设置密钥口令
ssh-keygen -t ed25519 -C "dev@example.com"
ssh-copy-id username@192.168.1.100

# 验证免密登录
ssh username@192.168.1.100

免密登录配好后，建议立刻修改 /etc/ssh/sshd_config，关闭 root 直接登录和密码认证，只允许密钥登录。改完 sudo systemctl restart ssh 生效——重启前务必保留一个已登录的会话，否则配置写错会把自己锁在门外。

6. 开发环境实战搭建

6.1 Python 环境与虚拟环境隔离

Ubuntu 24.04 默认自带 Python 3.12，22.04 是 3.10。系统 Python 不要乱动，很多系统工具依赖它。做项目应该用 venv 或 conda 隔离：

bash复制# 安装 venv 和 pip 支持
sudo apt install -y python3-pip python3-venv python3-dev

# 创建独立虚拟环境，避免污染系统 Python
python3 -m venv ~/venvs/demo
source ~/venvs/demo/bin/activate
python -V
pip install --upgrade pip

24.04 引入了 PEP 668 保护，直接 pip install 到系统环境会报 externally-managed-environment 错误。这不是 bug，是防止你装坏系统包。正确做法就是上面这样用虚拟环境，或者在明确知道风险时加 --break-system-packages 参数（不推荐在系统环境这么干）。

pip 下载慢可以配置国内镜像：

bash复制# 写入用户级 pip 配置，只影响当前用户
mkdir -p ~/.pip
cat > ~/.pip/pip.conf <<'EOF'
[global]
index-url = https://pypi.tuna.tsinghua.edu.cn/simple
trusted-host = pypi.tuna.tsinghua.edu.cn
EOF

6.2 Node.js 安装

apt 源里的 Node 版本通常偏旧，做前端项目建议用 NodeSource 源或 nvm。nvm 的好处是能在多版本之间切换，不污染系统：

bash复制# 安装 nvm 并加载
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc

# 安装并用 LTS 版本
nvm install --lts
nvm use --lts
node -v
npm -v

如果网络访问 GitHub 不稳定，改用 NodeSource 的 apt 源也可以，安装脚本会自己处理仓库配置。装完记得配置 npm 镜像，否则装依赖会非常慢：

bash复制npm config set registry https://registry.npmmirror.com
npm config get registry

6.3 Docker 安装与权限配置

Docker 是 Ubuntu 上性价比最高的一个工具，装了它之后数据库、缓存、消息队列基本都不用在本机编译安装。推荐用官方 apt 仓库而不是 snap 版本，snap 版的路径隔离和挂载行为经常让人困惑：

bash复制# 添加官方 GPG 密钥和仓库
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

装完把当前用户加入 docker 组，这样就不用每条命令都加 sudo。注意这一步等同于给了该用户 root 级权限，只在可信机器上做：

bash复制sudo usermod -aG docker $USER
newgrp docker

# 验证
docker version
docker run --rm hello-world

再配一下镜像加速和日志限制，不然跑一段时间磁盘就被日志撑满：

json复制{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "3"
  }
}

写入 /etc/docker/daemon.json 后执行 sudo systemctl restart docker 生效。max-size 和 max-file 这两个参数建议所有生产机器都配上，默认不限制日志大小是磁盘爆满的头号原因。

6.4 Git 与开发习惯配置

bash复制git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
git config --global core.autocrlf input

# 生成 SSH 密钥用于代码托管平台
ssh-keygen -t ed25519 -C "you@example.com"
cat ~/.ssh/id_ed25519.pub

core.autocrlf input 在 Linux 上作用有限，但如果你会和 Windows 协作，这个配置能避免换行符导致的整文件 diff。

7. 服务部署实战：Nginx 与 systemd

7.1 安装并验证 Nginx

装一个 Nginx 来验证整套系统是否可用，这是最直观的端到端检查：

bash复制sudo apt install -y nginx
sudo systemctl enable --now nginx
sudo systemctl status nginx --no-pager

# 本机自测
curl -I http://127.0.0.1

# 放行防火墙
sudo ufw allow 'Nginx Full'
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

curl -I 返回 HTTP/1.1 200 OK 就说明 Web 服务正常。如果本机能通、外部访问不通，九成是防火墙没放行或者云厂商安全组没开端口，按这个顺序查。

站点配置放在 /etc/nginx/sites-available/，然后软链到 sites-enabled/。反向代理一个后端服务的典型配置：

nginx复制# /etc/nginx/sites-available/demo.conf
server {
    listen 80;
    server_name demo.local;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 120s;
    }
}

启用并检查语法，语法错了不要 reload，否则会把现有服务搞挂：

bash复制sudo ln -s /etc/nginx/sites-available/demo.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

nginx -t 输出 syntax is ok 和 test is successful 两行才算通过。

7.2 用 systemd 托管自建服务

很多人习惯用 nohup python app.py & 起服务，这种方式 SSH 一断就可能挂，机器重启也不会自启。正确做法是写 systemd unit：

ini复制# /etc/systemd/system/demo-api.service
[Unit]
Description=Demo API Service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/opt/demo
Environment="PYTHONUNBUFFERED=1"
EnvironmentFile=-/opt/demo/.env
ExecStart=/opt/demo/venv/bin/python -m uvicorn main:app --host 127.0.0.1 --port 8000
Restart=always
RestartSec=3
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

加载并启动：

bash复制sudo systemctl daemon-reload
sudo systemctl enable --now demo-api
sudo systemctl status demo-api --no-pager

# 实时看日志，排查启动失败最有效的手段
sudo journalctl -u demo-api -f --no-pager

Restart=always 加 RestartSec=3 能让服务在异常退出后自动拉起，这是自建服务稳定性的最低保障。EnvironmentFile 用来放密钥和数据库密码，文件权限设成 600，不要写进 unit 文件里，否则任何能读 unit 的人都能看到密码。

7.3 服务可用性验证

部署完做一轮完整验证，不要只看进程在不在：

bash复制# 服务端口监听状态
ss -tlnp | grep -E '80|8000'

# 接口连通性
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8000/health

# 模拟重启，验证开机自启是否真的生效
sudo reboot

重启后重新登录，systemctl status 显示 active、curl 返回 200，才算真正部署完成。只测当前会话不测重启，是自建服务最常见的自欺欺人。

8. 资源占用与性能观察

Ubuntu 桌面版空载时内存占用大约在 1.2GB 到 2GB 区间，具体取决于桌面环境和后台服务；服务器版最小安装空载可以压到 200MB 到 400MB。这个数字不需要死记，用自己的机器跑一遍 free -h 建立基线才有意义。基线的作用是：当你发现内存从 800MB 涨到 6GB 时，能立刻判断是业务涨了还是内存泄漏。

日常观察用这几个命令就够：

bash复制# 总体资源概览，htop 更直观，支持鼠标和树状进程
htop

# 按内存排序看前 10 个进程
ps aux --sort=-%mem | head -n 11

# 磁盘使用率和 inode 使用率，inode 满了也会报“no space left”
df -hT
df -i

# 磁盘 IO 情况
iostat -x 1 5

# 找出根目录下占用最大的目录
sudo du -h --max-depth=1 / 2>/dev/null | sort -rh | head -n 15

df -i 这条经常被忽略。有一种故障是 df -h 显示还有空间，但写入报 No space left on device，原因是小文件太多把 inode 用光了，典型场景是大量会话文件、缓存碎片、邮件队列。遇到这种先查 inode 再查容量。

GPU 机器装好 NVIDIA 驱动后，用 nvidia-smi 观察显存和利用率。驱动安装推荐用 Ubuntu 自带的工具，它会自动匹配适合当前硬件的版本：

bash复制# 查看可用驱动并自动安装推荐版本
ubuntu-drivers devices
sudo ubuntu-drivers autoinstall
sudo reboot

# 重启后验证
nvidia-smi

nvidia-smi 能正常输出表格，说明驱动和内核模块都加载成功了。如果报 NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver，通常是 Secure Boot 拦截了未签名模块，或者内核升级后模块没重新编译，处理方式是回 BIOS 关闭 Secure Boot，或者执行 sudo apt install --reinstall 对应驱动包重新构建。

性能调优上有几个实际有效的方向。内存紧张时优先调小 swap 倾向参数 vm.swappiness，默认 60 对桌面合适，服务器可以降到 10；磁盘 IO 高时先确认是不是日志在狂写，用 iotop 定位到具体进程；容器环境要限制每个容器的 CPU 和内存上限，不要指望宿主机自动均衡；网络吞吐异常先用 iftop 或 nload 看流量方向，再查是不是被扫描或被当成代理跳板。

9. 常见问题与排查方法

装机和使用过程中会撞见的问题高度集中在几类。下面这张表覆盖了发生频率最高的场景，遇到问题按“现象—原因—排查—解决”的顺序走，比盲目搜索效率高得多。

几个高频问题单独展开说。

apt 锁的问题几乎每个人都会遇到一次，典型场景是开了两个终端同时跑 apt，或者上次 apt 被 Ctrl+C 中断。直接删锁文件是有风险的，正确顺序是先确认没有 apt 进程在跑，再清理：

bash复制# 先确认没有残留进程
ps aux | grep -E 'apt|dpkg' | grep -v grep

# 修复中断的安装
sudo dpkg --configure -a
sudo apt --fix-broken install

# 确认无进程后再清理锁
sudo rm -f /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock
sudo apt update

双系统时间不一致的原因很明确：Windows 默认把 BIOS 时间当本地时间，Linux 默认当 UTC。两种解法，选一种坚持用。第一种是让 Linux 迁就 Windows：

bash复制timedatectl set-local-rtc 1 --adjust-system-clock

第二种是让 Windows 改用 UTC，这个方法更干净，但需要改注册表：在 Windows 里以管理员身份执行 reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f，然后重启。推荐第二种，因为服务器环境本来就该用 UTC。

磁盘空间不足要先定位再删。盲目 rm -rf 是事故高发区，尤其别对 /var、/usr 下手。安全的清理顺序是：先清 apt 缓存 sudo apt clean，再限制 journal 日志大小 sudo journalctl --vacuum-size=200M，然后清 Docker 无用镜像 docker system prune -a，最后才考虑手动删具体文件。清理前用 du 排序看清楚是谁占的，别靠猜。

10. 最佳实践与长期维护

第一条，版本选型锁定 LTS，并且不要开自动全量升级。unattended-upgrades 默认只装安全更新，这是合理的；如果手动把 apt upgrade 写成定时任务，某天内核升级把驱动搞挂，机器重启后直接失联。生产机器的升级节奏应该是：先在测试机验证，确认驱动和服务正常，再灰度到正式环境。

第二条，装完系统立刻做一次快照或备份。虚拟机直接打快照，物理机用 timeshift 做系统快照，服务器至少备份 /etc 和关键数据目录。这套动作花十分钟，能在后面省掉几小时的重装时间。重装系统很容易，重配环境和找配置文件才痛苦。

第三条，目录结构从一开始就分清。系统盘只放系统和软件，数据放独立分区或独立磁盘。日志、缓存、Docker 数据目录都单独规划，/var/lib/docker 尤其容易膨胀。做 AI 的把数据集、模型权重、输出结果分三个目录管理，命名带日期和版本号，不然一周之后就分不清哪个权重是哪个实验产出的。

第四条，配置一切皆文件，并且纳入版本管理。/etc/nginx、systemd unit、netplan 配置、Docker compose 文件，这些都该有个 git 仓库或者至少有个备份目录。手工改配置不留记录，是团队协作里最容易引发“昨天还好好的”这类事故的原因。

第五条，权限最小化。不要日常用 root 登录，不要给所有用户 sudo，不要把密钥文件设成 777，不要在 unit 文件里写明文密码。/opt/demo/.env 这种文件的权限应该是 600 并且属主是服务运行用户。Docker 组的权限等同于 root，只给需要的人加。

第六条，服务必须可观测。至少要有三样东西：进程状态（systemd 能自动拉起）、日志（journald 或文件日志，带轮转）、健康检查接口（一个返回 200 的 /health）。没有这三样，出问题时你只能靠重启碰运气。

第七条，涉及数据和内容的功能要守住合规线。部署任何采集、分析、生成类服务之前，确认数据来源合法、用户授权明确、敏感信息脱敏、访问范围可控。涉及人像、声音、版权的素材，必须取得授权后再处理，不要拿网上的素材直接跑。这类风险不是技术问题，技术再好也兜不住。

第八条，养成写脚本的习惯。装完一台机器，把换源、装包、配 SSH、装 Docker 这些步骤写成 shell 脚本，下次装机器直接跑。跑三次以上的操作就该自动化，这是把“会装系统”升级成“能批量交付”的分界线。脚本要注意幂等性，重复执行不报错、不重复追加配置，最简单的做法是先判断再写入。

最后给一个轻量的验证清单，装完一台新机器照着过一遍，基本能确认这台机器是健康的：

bash复制#!/usr/bin/env bash
# 新装机自检脚本，仅做只读检查，不修改系统状态
set -u

echo "== 系统信息 =="
lsb_release -ds; uname -r

echo "== 磁盘 =="
df -hT | grep -Ev 'tmpfs|loop'

echo "== 内存 =="
free -h

echo "== 服务状态 =="
for s in ssh nginx docker; do
  printf '%-8s ' "$s"
  systemctl is-active "$s" 2>/dev/null || echo "not-installed"
done

echo "== 监听端口 =="
ss -tlnp | head -n 15

echo "== 时间同步 =="
timedatectl | grep -E 'Time zone|synchronized'

Ubuntu 这条链路走下来，真正值得先验证的是三件事：网络能不能通（换源、DNS、防火墙）、服务能不能自启（systemd 加重启测试）、日志能不能看（journalctl 能定位问题）。这三件通了，剩下的软件安装都是体力活。最容易踩的坑集中在显卡驱动、双系统引导、apt 锁和磁盘空间四处，本文的排查表基本覆盖了。后续要扩展的方向也很清楚：往容器化走就深挖 Docker Compose 和 K8s，往 AI 走就补 CUDA 和驱动版本管理，往运维走就上 Ansible 做批量配置。基础系统这一层稳住，上面盖什么都不会太歪。建议把本文的安装步骤和自检脚本收藏备用，重装的时候能省不少时间。