简介这是一份面向Ubuntu新手与进阶开发者的系统使用教程和资源指南围绕安装初始化、终端管理、性能调优、开发环境搭建及实战部署展开帮助读者从零上手并熟练运用容器化、Python虚拟环境、LAMP建站等技能。资源为1个docx文档整包约21KB轻便易读目前已有1126人学习下载。内容按2025年最新视角组织新手部分涵盖官方ISO启动盘制作、UEFI/BIOS分区方案、apt命令与软件管理进阶部分详解systemd-analyze开机加速、htop资源监控、Docker引擎安装及用户组配置、venv虚拟环境创建。实战项目包括基于LAMP搭建Web服务、Bash自动化脚本、Docker Compose编排WordPressMySQL以及Harbor私有仓库搭建并针对依赖冲突、NVIDIA驱动兼容等常见问题给出排错思路还延伸至AI开发环境与边缘计算场景。适合希望系统学习Ubuntu使用、优化系统并开展实际项目的人群按需查阅。1. 从装系统到跑环境这份 Ubuntu 资源到底能帮你走多远很多人拿到 Ubuntu 教程的第一反应是“装个系统谁不会”结果卡在分区、驱动、软件源这些细节上一折腾就是一下午。这份《Ubuntu 使用教程与资源指南》的定位很明确它不是单纯讲命令的手册而是把新手入门、系统调优、开发环境、容器部署和排错串成一条完整链路从官方 ISO 制作启动盘一直讲到 Docker Compose 和 AI 环境搭建。适合刚接触 Linux 的学生、准备把开发机迁到 Ubuntu 的从业者以及想用 Docker 统一开发与部署环境的人。照着走能把系统装明白也能把环境配得不那么“玄学”。2. 磁盘分区与软件管理装完系统先做的三件事2.1 分区方案为什么 / 单独分、swap 设成内存 2 倍资源里推荐的分区思路很朴素/分 30GB、/home分剩余空间、swap设为内存的 2 倍。这个方案在 2025 年的 SSD 时代依然能打原因有三根目录独立系统重装时用户数据不受影响/home单独挂载备份时只需打包一个分区swap 给足余量编译大型项目或跑容器时不至于被 OOM 杀掉。实际安装时我一般会在 UEFI 模式下额外分一个 512MB 的 EFI 分区这是很多人第一次装机会忽略的点。分区表选择 GPT传统 BIOS 模式则采用 MBR。以下是在 Ubuntu 安装器“其他选项”里的手动分区操作参考# 假设你的磁盘是 /dev/sda安装器界面里按下 CtrlAltF2 可打开终端 # 查看磁盘信息确认目标设备 lsblk # 创建分区表示例实际操作在图形界面完成这里对应分区意图 # /dev/sda1 512MB EFI System Partition - 挂载点 /boot/efi # /dev/sda2 30GB ext4 - 挂载点 / # /dev/sda3 8GB swap - 交换空间 # /dev/sda4 剩余全部 ext4 - 挂载点 /home逻辑说明lsblk用于查看块设备布局确认哪块盘是目标盘避免装错磁盘。EFI 分区必须格式化为 FAT32 并挂载到/boot/efi否则 UEFI 启动模式无法引导。/分配 30GB 在只装基础系统和开发工具时够用但如果你打算装多个桌面环境或大型软件建议提到 50GB。swap设为内存 2 倍是保守做法主要用于休眠功能如果不需要休眠用 8GB 固定大小或者干脆用 swapfile 也可以。分区完成后第一次进系统的标准动作是更新源并安装基础工具链sudo apt update sudo apt upgrade -y # 更新软件源索引并升级现有软件包 sudo apt install -y build-essential # 安装 GCC、G、make 等编译工具链参数说明update只刷新软件包列表upgrade才真正升级已安装软件所以两个命令必须连着跑。-y是自动确认避免交互式提问卡住脚本。build-essential包含编译 C/C 程序所需的完整工具集后续编译源码、安装 Python 扩展包几乎都依赖它。2.2 软件源apt 的 update 与 upgrade 为什么不能混着用资源里对 apt 命令做了分组但没有强调 update 与 upgrade 的真实差异。很多新手第一次跑sudo apt upgrade发现输出很长、下载很多于是误以为“系统出问题了”。其实 update 只是把远程仓库的索引拉到本地类似更新的元数据upgrade 拿着这份新索引去比对本地已装包决定要升级哪些。如果跳过 update 直接 upgradeapt 拿到的还是旧索引要么提示“无法定位软件包”要么升级到旧版本列表里的最新版容易漏装新依赖。另一个坑是apt upgrade不会自动处理内核版本升级如果你看到 Ubuntu 提示有新内核但升级列表里没有需要用apt full-upgrade或在图形界面的 Software Updater 里处理。这块内容资源里没有细讲属于典型的新手卡点。2.3 软件管理install、remove、purge 的边界与清理习惯资源里的软件管理命令保留了最常用的三条我在实际使用中会把它们扩展成一个“安装-卸载-清理”闭环apt search python3-venv # 搜索包含 python3-venv 的软件包 apt install -y python3-venv # 安装指定包及其依赖 apt remove --purge -y python3-venv # 卸载软件并删除配置文件 apt autoremove -y # 清理卸载后残留的孤立依赖参数说明search支持正则表达式搜索结果里带installed标记的是已装包。remove保留配置文件purge连配置一起删团队运维时我通常只用purge避免旧配置文件干扰重装。autoremove是很多人不知道的收尾动作——卸载某个软件后它当初自动拉进来的依赖会变成孤儿包占用磁盘空间这条命令就是清理这些依赖的。到这里系统层面的安装、更新、卸载操作已经闭环。资源里的进阶部分在此基础上加了系统调优和开发环境搭建关于 Python 虚拟环境和 Docker 的细节我会在后续章节展开先把系统跑稳再谈容器。3. 系统调优与开发环境让本机跑出服务器该有的样子3.1 开机加速systemd-analyze 定位慢服务而不是瞎禁功能资源里给的开机加速思路是systemd-analyze blame分析耗时服务然后disable掉非必要项。这条思路对但执行起来有个隐藏风险disable不等于mask前者只是取消开机自启后者会把服务彻底锁死。新手容易把这两个概念混淆禁了一个看似没用的服务结果某个功能依赖它运行时报错半天查不出原因。我的操作流程是先量化再处理# 查看总启动时间与各阶段耗时 systemd-analyze # 按耗时排序显示每个服务占用的启动时间 systemd-analyze blame | head -20 # 确认服务是什么、被谁依赖之后再决定是否禁用 systemctl status [服务名] systemctl list-dependencies [服务名] --reverse # 确认无用后禁用开机自启不停止当前运行 sudo systemctl disable [服务名] # 如果以后要恢复sudo systemctl enable [服务名]参数说明blame输出的是服务初始化占用的时间head -20只取前 20 条通常都是图形桌面、网络管理、云服务等大头。list-dependencies --reverse查看反向依赖——也就是“谁在依赖这个服务”这步是避免禁错的关键。disable只撤销开机自启服务本身仍在随时可以start。实际环境里我遇到最多的启动慢元凶是NetworkManager-wait-online.service它要等网络就绪才继续启动流程装云服务器版尤其明显。还有一个是snapd系列服务如果你不用 Snap 包可以考虑禁用部分 snap 服务的开机自启但注意不要动snapd主服务本身否则系统图形环境可能出问题。3.2 资源监控htop 与 glances 各自该在什么场景用资源里提到 htop 和 glances两者定位不同htop 是增强版 top单机交互式查看进程、CPU、内存胜在轻量直观glances 是全能型监控支持 Web 模式、历史趋势、容器状态汇总适合挂在后台做持续观测。我在本地排查问题时多用 htop在服务器上做巡检时开 glances。sudo apt install -y htop glances htop # 键盘 F6 选择排序字段F9 kill 进程 glances # 默认显示全屏面板按 1 展开 CPU 核心按 d 切换到磁盘 I/O参数说明htop 按 F6 进入排序列选择界面选PERCENT_CPU可以快速定位 CPU 占用最高的进程这一步比 top 的批处理输出直观得多。glances 默认每 1 秒刷新一次按s可设置刷新间隔它的 Web 模式用glances -w启动默认监听 61208 端口适合用浏览器远程查看。资源里只说了“实时查看”实际用的时候把这两个工具拆开看效率和体验差别很大。3.3 Python 虚拟环境venv 与 conda 的边界以及 CUDA 基础资源里给的 venv 命令是创建项目隔离环境的正确姿势但有一个前提容易被忽略python -m venv myenv依赖系统 Python 版本而 Ubuntu 24.04 默认自带的是 Python 3.12如果你的项目要求 Python 3.10 或 3.11venv 直接打通不了。这时候有两个选择用uv或者 pyenv 管理多 Python 版本再针对具体版本创建 venv或者直接用 conda 系列创建独立环境conda 会自带匹配的 Python 解释器省去切换版本的麻烦。# 系统 Python 3.12 上手最直接的方式 python3 -m venv ~/myenv source ~/myenv/bin/activate pip install --upgrade pip # 查看虚拟环境中的 Python 与 pip 路径确认没有指向系统目录 which python which pip # 退出虚拟环境 deactivate参数说明激活环境后which python应指向~/myenv/bin/python如果没有指向说明激活失败或系统 PATH 优先级异常需要检查echo $PATH。pip install --upgrade pip是每次新建虚拟环境后的习惯动作因为系统自带的 pip 版本往往落后安装某些包时会触发依赖解析报错。CUDA 相关部分资源里只提了一句“CUDA Toolkit PyTorch 搭建深度学习工作站需 NVIDIA 显卡”。这块我多说一句装 CUDA 前先用nvidia-smi查看驱动版本支持的 CUDA 版本号再决定装哪个 Toolkit否则会出现驱动最高支持 CUDA 12.4、你却装了个 CUDA 12.6 Toolkit 的窘境跑 PyTorch 时报 CUDA 版本不匹配。Ubuntu 下安装驱动用ubuntu-drivers autoinstall是省心方案但它会安装推荐版本而非最新版本追求最新驱动的用户需要去官方查询对应型号这个在后面的避坑小节里细说。4. Docker 与项目实战一条命令复现整条开发链4.1 Docker 引擎安装curl 脚本与手动安装的取舍资源里给的 Docker 安装方式是官方一键脚本这确实是最快的路径curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER注意usermod -aG docker需要退出当前会话再重新登录才会生效执行后docker ps如果提示权限不足先执行newgrp docker临时切换组身份或者干脆注销重登。这一步不生效是入坑率最高的点。参数说明-fsSL中f表示失败时不输出 HTML 错误页面s静默模式S显示错误L跟随重定向。脚本会检测发行版并自动配置官方源。如果你所在网络环境访问官方源慢可以改用国内镜像源脚本或者安装后用daemon.json配置镜像加速器这个后文讲。4.2 Docker Compose 编排多服务nginx 与 mysql 的配置陷阱资源里的 Compose 示例是一个 nginx mysql 的简单组合实际部署时这个“简单组合”有两个隐藏陷阱。第一image: mysql:8.0没有指定 platform在 ARM 架构机器上会拉不到匹配镜像需要在services.db里加platform: linux/amd64或用对应 ARM 版本镜像。第二mysql:8.0首次启动会要求设置 root 密码你的environment里给了MYSQL_ROOT_PASSWORD但没设置数据库名和用户应用连库时会因为找不到指定库而报错。version: 3.8 services: web: image: nginx:latest container_name: web-nginx ports: - 80:80 - 443:443 volumes: - ./html:/usr/share/nginx/html - ./nginx.conf:/etc/nginx/conf.d/default.conf restart: unless-stopped depends_on: - db db: image: mysql:8.0 container_name: web-mysql platform: linux/amd64 environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: myapp MYSQL_USER: appuser MYSQL_PASSWORD: apppass volumes: - db_data:/var/lib/mysql ports: - 3306:3306 restart: unless-stopped volumes: db_data:参数说明version字段在 Compose V2 以下版本有实际意义V2 以上已经忽略它保留只是为了兼容旧写法。depends_on只控制启动顺序不保证数据库真正就绪所以应用服务需要自己做重试连接这也是“顺序依赖”与“健康依赖”的常见误区。ports: 80:80是宿主机端口:容器端口宿主机 80 被占用时改成8080:80即可。volumes里的db_data是具名卷数据会存到 Docker 管理的卷目录中删除容器不会丢数据。这套配置在本地跑通后配合以下命令管理整个生命周期# 启动全部服务并挂到后台 docker compose up -d # 查看服务日志确认 nginx 与 mysql 都正常 docker compose logs -f # 进入容器内调试 docker exec -it web-mysql mysql -u appuser -p # 修改配置后重建受影响的容器 docker compose up -d --force-recreate web4.3 私有镜像仓库从本地 registry 到企业级选型资源里提到的 Harbor 属于企业级方案但本地开发阶段用 Docker 自带的 registry 镜像更轻量。一条命令起一个私有仓库sudo docker run -d -p 5000:5000 --name registry registry:2然后给本地镜像打标签并推送sudo docker tag myapp:latest localhost:5000/myapp:latest sudo docker push localhost:5000/myapp:latest参数说明默认 registry 是 HTTP 协议本机访问没问题但其他主机想用它需要把该主机的地址加入 Docker 客户端的insecure-registries配置否则推送时会被 TLS 证书校验拦下。Harbor 走的是 HTTPS 完整权限体系适合多团队共享镜像的场景但配置复杂度也高一个量级。我的建议是个人项目用 registry团队协作直接上 Harbor中间态的过渡方案意义不大。5. 排错与防翻车依赖冲突、驱动与容器排查记录5.1 aptitude 解决依赖冲突不是万能药现象apt install python3-pip提示依赖关系无法满足有的包建议apt -f install修复但是修复到一半又提示破坏另一个包。原因软件源里某个包的两个版本之间存在冲突常见于混合了不同的 Ubuntu 发行版源例如把 22.04 源的包装到了 24.04 系统上或者手动装了第三方 .deb 包篡改了依赖树。解决用 aptitude 的交互式方案选择器处理它能列出多种依赖解决方案按字母或数字选择最合适的一套sudo apt install aptitude sudo aptitude install python3-pip进入交互界面后按e查看每个方案的具体动作选中“保留当前版本并取消另一个包的升级”之类的方案按g应用。如果你不想交互直接跑sudo aptitude -y install python3-pip它会自动选择一个可行的方案但自由度低一些。多试几次加减-y和-r组合能应付大多数情况。这里要说清楚边界aptitude 不是万能的根因是软件源配置混乱导致的环境脏。我踩过最深的一次是在某台长期测试机上混用了多个 Ubuntu 版本源aptitude 几乎无法收敛到稳定状态最后是写了个脚本把第三方源全部注释掉、apt update、再apt upgrade重置依赖树解决的。换句话说aptitude 是救火工具清理源配置才是基本功。5.2 安装 NVIDIA 驱动后循环登录或桌面白屏现象执行sudo ubuntu-drivers autoinstall重启后登录界面输入密码闪一下又跳回登录界面或者进桌面后白屏。原因新装驱动与当前内核版本不匹配或者 Secure Boot 阻止了内核模块加载。Ubuntu 默认开启的 Secure Boot 要求驱动模块有签名自动安装的驱动若未正确签名系统启动时直接拒载。解决先确认 Secure Boot 状态再决定走哪条路# 查看系统是否开启 Secure Boot mokutil --sb-state # 查看当前的 nvidia 模块状态若 loaded 则驱动已加载 lsmod | grep nvidia # 尝试导入驱动模块若报 Operation not permitted基本可以断定是签名问题 sudo modprobe nvidia如果确认 Secure Boot 已开启最简单的方式是在安装驱动时进行模块签名具体做法是装驱动前先安装mkosi签名工具链或者去 BIOS 里关闭 Secure Boot个人电脑上这是常见做法。关闭后重新装驱动并重启sudo apt remove --purge -y nvidia-* sudo ubuntu-drivers autoinstall sudo reboot讲一个我自己的血泪经验在某台测试机上我没检查 Secure Boot装完驱动重启后连续三次回到登录界面还以为是显示管理器坏了折腾了一个多小时最后用 modprobe 测试才发现是模块加载被拒。从那以后我每次装显卡驱动前会固定跑一遍mokutil --sb-state和sudo dmesg | grep -i nvidia确认模块加载状态再动手这条流程也建议新手照着走。5.3 Docker 容器端口占用与静态 IP 配置现象docker compose up -d时提示port is already allocated服务起不来或者容器内服务正常宿主机访问不到。原因宿主机的 80 端口已被占用比如你自己装过 nginx或者 Docker 默认的 bridge 网络无法满足容器间固定 IP 通信需求。解决第一步排查占用情况第二步换端口或换网络模式# 查看哪些进程占用 80 端口 sudo ss -tlnp | grep :80 # 先停掉占用端口的服务或者改 Compose 映射端口 sudo systemctl stop nginx sudo docker compose up -d # 如果需要容器固定 IP改为自定义 bridge 网络 sudo docker network create --subnet192.168.50.0/24 mynet参数说明ss -tlnp比netstat更直观-t显示 TCP-l只显示监听端口-n不做 DNS 反解-p显示进程信息这一步能把占用端口的“真凶”揪出来。自定义 bridge 网络的--subnet要避开宿主局域网的 IP 段否则会和物理网络冲突。固定 IP 的配置方法是在 Compose 文件的services下加networks: mynet: ipv4_address: 192.168.50.10这个操作资源里没写但实际部署数据库或主从架构时几乎必用。5.4 误删系统包后的后悔药现象想卸载某个不用的软件用了sudo apt remove --purge结果连带着把桌面环境、网络管理等系统组件一起卸了重启后系统起不来。原因apt 处理依赖时多个主要组件如 ubuntu-desktop都依赖某些公共库你把提供这个公共库的包 purge 掉后apt 判定所有依赖它的包都变成孤包一并移除。解决立刻从 recovery 模式或 Live USB 启动挂载根分区后 chroot 进入系统重新安装关键元包# 在 Live 环境里挂载根分区并 chroot sudo mount /dev/sda2 /mnt sudo mount --bind /dev /mnt/dev sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo chroot /mnt /bin/bash # 把桌面环境和基础工具补回来 apt install --reinstall ubuntu-desktop network-manager逻辑说明mount --bind是把 Live 系统的 /dev、/proc、/sys 挂到目标系统的对应目录确保 chroot 后内核接口可用。--reinstall会强制重装指定包而不卸载依赖。这个操作的前提是你知道删掉的元包到底是什么如果拿不准也可以从/var/log/apt/history.log里查最近一条 apt 记录。我的习惯是每次卸载数据包前先看一眼apt-cache rdepends的输出确认没有核心组件依赖它再动手。6. 验证与提速开机时间、依赖锁定与镜像源最后一公里资源看完后最重要的动作是验证自己有没有白折腾。我通常用一套固定的验收流程先记录优化前的基线再改配置最后对比数据而不是凭感觉判断“好像变快了”。第一件事是量化开机数据。系统刚装好时先跑一遍systemd-analyze记录总耗时禁用慢服务和精简 snap 后再跑一遍对比数字这一招最直接systemd-analyze # 记录优化前基线 systemd-analyze blame | head -10第二件事是给开发环境加锁。用 venv 创建环境时顺手生成 requirements但真正的锁定是冻结完整版本pip freeze requirements.lock pip install -r requirements.lock相比requirements.txt手动写主依赖freeze会把所有传递依赖和精确版本一并锁住。这个习惯在团队协作里价值最大任何机器装出来的环境都是一模一样的。第三件事是镜像源配置的收尾。资源里只提到官方源但国内网络下官方源慢到怀疑人生换阿里云或清华源是最常用的加速手段sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo sed -i s/archive.ubuntu.com/mirrors.aliyun.com/g /etc/apt/sources.list sudo apt updateDocker 部分同理在/etc/docker/daemon.json里写镜像加速器然后重启 Docker 服务{ registry-mirrors: [https://docker.mirrors.ustc.edu.cn] }sudo systemctl restart docker这些收尾工作做完整台机器的安装、调试、验证链路就闭环了。我从那次显卡驱动翻车之后每次给机器布置环境都强制走一遍“基线记录、改配置、对比验证、锁定依赖”的流程也习惯在改任何源或服务前先备份一份配置文件后悔药随时能吃上。希望这些从资源里提炼出来的实操细节能帮你少走几段弯路把 Ubuntu 真正用成趁手的开发工具。本文还有配套的精品资源点击获取