ROS/ROS2 一键安装与避坑：版本选型、环境配置、报错排查

1. 装 ROS 之前，先搞懂它为什么会把人劝退

1.1 一次真实的翻车现场

帮刚进实验室的师弟配环境，一台重装完的 Ubuntu 22.04，目标是 ROS 2 Humble。从下午两点折腾到晚上七点，卡点有三个：apt update报 GPG 密钥过期导致源被跳过、rosdep init死活拉不到索引、还有他自己之前装的 conda 把系统 Python 顶掉了，编译工作空间时报一堆找不到empy的错。整个过程里没有一个是"ROS 本身有问题"，全是环境层面的连锁反应。

这就是 ROS 和 ROS2 安装的典型形态：软件本体其实只是几十个 deb 包，真正难缠的是它对系统的要求——特定的 locale、匹配的 Python 版本、能正常解析的软件源、独立的依赖管理体系 rosdep。任何一环不对，报错信息都会指向一个和你实际做错的地方完全无关的方向。新手最容易在这里产生"我是不是不适合搞机器人"的自我怀疑。

一键安装脚本解决的正是这个问题。它把版本判断、换源、密钥导入、依赖补齐、rosdep 初始化这一整套动作打包成几个菜单选项，你只需要回答"我装 ROS 还是 ROS2""装哪个版本""要不要顺便换源"，剩下的它自己跑。对绝大多数只想尽快看到小海龟动起来的人来说，这是最短路径。

1.2 一键安装脚本到底替你做了什么

很多人用完一键脚本，其实不清楚它背后动了哪些文件。这会导致后面出问题时完全没有排查方向。按常见实现来看，一个完整的安装流程大致包含这么几类动作。

第一类是系统层面的预处理：检查当前 Ubuntu 版本号和架构，修正 locale 为 UTF-8，备份/etc/apt/sources.list，把官方源替换成就近的公共镜像站，然后执行一次完整的apt update && apt upgrade。第二类是密钥与源列表：下载 ROS 仓库的 GPG 公钥并写入/usr/share/keyrings/，再往/etc/apt/sources.list.d/里放一个对应发行版的.list文件。

第三类是包安装：根据你选的是桌面完整版还是基础版，执行类似apt install ros-humble-desktop或ros-noetic-desktop-full的命令，同时补上编译工具链、Python 依赖、colcon、vcstool这些配套组件。第四类是收尾：往~/.bashrc追加环境变量 source 语句，执行rosdep init和rosdep update，最后打印一段验证提示。

提示：脚本能替你跑命令，但不能替你理解环境。建议在执行前把脚本下载到本地，用cat或编辑器通读一遍，重点看它改了哪些系统文件、往~/.bashrc里追加了什么内容。这份阅读成本大概十分钟，但能让你在后续出问题时知道该回滚什么。

1.3 哪些人不适合用一键脚本

说句实话，一键脚本不是万能的。有几种情况我建议老老实实手动装。

一种是你要在生产设备、工控机或者客户现场部署，环境必须完全可追溯，每一个包从哪来、版本锁在多少，都要写进文档。这种情况下用交互式脚本装出来的环境反而不好维护，因为版本是脚本作者替你选的，可能随着脚本更新而变化。另一种是你的系统已经被折腾得很乱——装过三四个版本的 Python、动过系统库、改过大量 apt 源——这时候脚本的"自动判断"很可能判断错，反而把问题埋得更深。

还有一种是要做课程设计或者毕设答辩的同学。答辩老师问一句"你这个 ROS 是怎么装的"，回答"一键脚本装的"和回答"我手动配了源、导了密钥、装了 desktop-full，然后初始化了 rosdep"，给分是不一样的。我的建议是：第一次装用脚本，快速把环境跑起来建立正反馈；等要做正式项目前，再在虚拟机里手动装一遍，把每一步都走通。这一遍的价值远超你的想象。

2. 版本选型：Ubuntu 和 ROS 的配对逻辑

2.1 版本对应关系速查

ROS 和 Ubuntu 是强绑定关系，一个 ROS 发行版只官方支持一到两个 Ubuntu 版本，装错版本是新手最高频的翻车原因。下面这张表建议直接存下来。

几个关键结论：ROS 1 的最后一个版本是 Noetic，只跑在 Ubuntu 20.04 上，官方维护已经在 2025 年 5 月结束。也就是说，现在新起项目，除非必须复用老代码或者老硬件驱动，否则没有理由再选 ROS 1。ROS 2 这边，Humble 是 22.04 上的长期支持版本，生态最成熟，第三方包覆盖最广；Jazzy 是 24.04 上的新一代 LTS，新特性更多但部分第三方库跟进还不完全。

顺带说一句，20.04 上能装的有 Foxy 和 Galactic 两个 ROS 2 版本，这两个都已停止维护，不建议新项目使用。如果你手里只有 20.04 的机器且想用 ROS 2，建议升级系统或者干脆上 22.04 虚拟机。

2.2 新手该怎么选：三个判断维度

选版本不要凭感觉，按下面三个维度过一遍，基本不会错。

先看硬件和驱动。如果你要用特定型号的激光雷达、工业相机、机械臂，去查厂商的 SDK 文档，它会写清楚支持哪个 ROS 版本、哪个 Ubuntu 版本。以机械臂为例，不少国产六轴臂的 ROS 驱动包只维护到 Noetic 或者 Humble，这种情况下你没得选，跟着厂商走。反过来，如果只用 Gazebo 做纯仿真，那就挑生态最厚的 Humble。

再看学习资料和社区。遇到报错时能不能搜到答案，直接决定你的学习效率。Humble 因为用户基数大，任何奇怪的报错基本都有前人踩过。Jazzy 相对新，部分问题你需要自己看源码解决。如果你是完全零基础，我个人建议 22.04 + Humble 起步，等把话题、服务、动作、参数、Launch 这一套吃透，再迁到 Jazzy 只是换个环境变量的事。

最后看你自己的开发节奏。如果这个环境要用两三年甚至更久，那就选支持周期长的：Humble 到 2027 年，Jazzy 到 2029 年。如果只是这学期做个课程作业，装完跑通就行，那用哪个都无所谓，哪个下载快用哪个。

2.3 硬件与虚拟机的准备工作

磁盘空间这事必须提前说。ROS 2 桌面版安装完大概占 2 到 3 GB，加上依赖、编译缓存、日志、后续自己装的 Gazebo 模型库，实际占用很容易到 15 GB 以上。所以给 Linux 分区至少留 40 GB，虚拟机的话建议 60 GB 起步，用精简置备或者动态分配就行。

虚拟机跑 ROS 有几个硬性要求。内存至少 4 GB，跑 Gazebo 建议 8 GB；CPU 给到 4 核；最关键的是要开启虚拟化加速和 3D 图形加速，VMware 里在虚拟机设置的"显示器"里勾上"加速 3D 图形"，VirtualBox 里在"显示"里启用 3D 加速并分配至少 128 MB 显存。不勾这个，RViz2 和 Gazebo 大概率黑屏或者直接崩。

原生安装还是虚拟机？如果你只是学概念、写节点、跑简单仿真，虚拟机完全够用，快照回滚还省心。如果要做视觉 SLAM、点云处理、深度学习推理这些吃 GPU 的活，虚拟机性能损耗会很明显，建议双系统或者干脆整机装 Ubuntu。另外 WSL2 也可以跑 ROS 2，但图形界面和网络通信需要额外配置，机械臂、串口设备这类外设透传也比较麻烦，我不太推荐新手从这个方向入门。

3. 一键安装实操：从执行脚本到小海龟跑起来

3.1 获取脚本与安全审查

社区里知名度最高的国内一键安装方案，是"鱼香 ROS"那一套交互式脚本，很多人叫它"鱼香肉丝一键安装"。它的特点是全中文菜单、覆盖 ROS 1 和 ROS 2 全版本、能自动处理换源和 rosdep 问题，对新手确实友好。

注意：安装脚本通常通过明文 HTTP 分发，这在原理上存在被中间环节篡改的可能。我的做法是先把脚本下载到本地而不立即执行，通读内容确认它只做换源、装包、写环境变量这三类动作，再手动运行。这一步不要省。

典型的获取方式是这样：

# 先下载到本地，不要直接管道执行 wget http://example.com/install -O ros_install.sh # 通读一遍内容 less ros_install.sh # 确认没问题再执行 bash ros_install.sh

网上流传的很多写法是wget xxx -O fishros && . fishros，把下载和执行串在一条命令里。方便是方便，但意味着你在没有看过任何内容的情况下就把脚本的权限交给了系统。养成"先下载、后阅读、再执行"的习惯，对以后处理任何第三方脚本都适用。

3.2 菜单选项逐条拆解

脚本跑起来之后，第一屏通常是一级菜单，大致是这几个选项：安装 ROS、安装 ROS2、配置 ROS 环境、安装常用工具、退出。你需要注意的不是选项名字，而是每一层选择背后的含义。

选"安装 ROS2"之后，第二屏会让你选版本，比如 Humble、Jazzy 或者"自动检测"。这里的自动检测是根据你的 Ubuntu 版本推断的，如果你用的系统版本比较特殊，自动检测可能给出一个并不合适的选项，手动指定更保险。第三屏一般是问你要不要更换系统软件源，这个强烈建议选"是"，并选一个离你网络位置近的镜像站，比如清华、中科大、阿里云。这一步能显著减少后面下载包的时间，也是手动装 ROS 时最容易忽略、最影响体验的一环。

再往后会问装桌面版还是基础版。桌面版包含 RViz2、仿真工具、示例程序，体积大但省事；基础版只有通信库和命令行工具，适合做瘦客户端或者 Docker 镜像。新手一律选桌面版。最后脚本会列出它准备执行的操作清单让你确认，这一屏值得花三十秒认真看，尤其是涉及覆盖配置文件的提示。

3.3 安装过程中的日志与时间预估

安装耗时差异很大，取决于镜像源速度和是否执行了系统升级。纯装 ROS 2 桌面版，镜像源良好的情况下十分钟左右；如果脚本先做一次完整系统升级，可能到二十分钟以上。国内镜像站在不同时段速度波动明显，如果卡在某个包长时间不动，可以中断后换一个镜像源重来。

日志里有两类输出要盯住。一类是Setting up ros-humble-xxx这样的成功信息，滚动过去就行。另一类是红色或黄色的错误，最常见的形态是Failed to fetch加一个包名，说明那个包没从镜像站拉到；或者The following packages have unmet dependencies，说明依赖冲突。

遇到个别的Failed to fetch，先不用慌，往往是镜像站同步延迟。等一两个小时或者换源后重新执行apt install通常就好。遇到依赖冲突，把完整的报错段落复制下来搜一下，一般能定位到是某个第三方源污染了依赖树。

3.4 装完立刻验证：ROS1 与 ROS2 两套命令

装完第一步是让环境变量生效。脚本一般已经写进~/.bashrc了，但当前终端还没加载，执行一次source ~/.bashrc或者直接开新终端。

ROS 2 的验证是这样两条命令，开两个终端分别跑：

# 终端 1 source /opt/ros/humble/setup.bash ros2 run demo_nodes_cpp talker # 终端 2 source /opt/ros/humble/setup.bash ros2 run demo_nodes_py listener

看到一边不断打印Publishing: 'Hello World: N'，另一边同步打印I heard: [Hello World: N]，说明话题通信链路完全正常。这一步的意义不只是"装成功了"，而是顺带验证了 C++ 和 Python 两套运行时、DDS 中间件的发现机制都在工作。

ROS 1 的验证更直观，跑个小海龟：

# 终端 1 source /opt/ros/noetic/setup.bash roscore # 终端 2 source /opt/ros/noetic/setup.bash rosrun turtlesim turtlesim_node # 终端 3：用键盘控制 rosrun turtlesim turtle_teleop_key

第三个终端里按方向键，海龟会动，就说明roscore、节点、话题、键盘输入全部打通。如果海龟窗口一片灰或者直接报错退出，多半是图形渲染问题，去查显卡驱动和虚拟机的 3D 加速设置。

4. 装完不等于能用：必须补的六项配置

4.1 环境变量与终端启动脚本

一键脚本通常在~/.bashrc末尾追加了一行source /opt/ros/humble/setup.bash。这么做的便利是每个新终端自动加载，代价是如果你之后装了 ROS 1 或者另一个 ROS 2 版本，两边会互相覆盖，出现"明明装了却找不到命令"或者"调用的库版本不对"的怪现象。

我的处理方式是不在~/.bashrc里写死，而是定义几个简短的别名或者函数：

# ~/.bashrc 里 alias ros2h='source /opt/ros/humble/setup.bash' alias ros1n='source /opt/ros/noetic/setup.bash' alias ros2j='source /opt/ros/jazzy/setup.bash'

需要哪个环境就在当前终端敲对应的别名。这样切版本的成本极低，也不会互相干扰。代价是每个新终端都要手动切一次，但换来的是环境可预测性，我认为完全值得。

另外ROS_DOMAIN_ID这个变量值得提一句。同一个局域网里的多个 ROS 2 设备默认会用同一个域，如果你的实验环境里有多台机器或者多人共用网络，节点会互相发现造成干扰。给每台机器分配不同的域 ID 能隔离掉这个问题。

export ROS_DOMAIN_ID=42

4.2 工作空间与编译工具链

ROS 2 用colcon作为构建工具，ROS 1 用catkin_make或catkin build。手动安装时这两个工具可能没被带上，一键脚本一般会装好，但值得确认一下。

创建一个标准工作空间并做一次空编译，能提前暴露很多工具链问题：

mkdir -p ~/ros2_ws/src cd ~/ros2_ws colcon build --symlink-install source install/setup.bash

--symlink-install这个参数我强烈建议每次都加。它的作用是用符号链接代替拷贝，改 Python 脚本后不需要重新编译，改 C++ 代码重新 build 时也更快。代价是 Windows 上不适用，纯 Linux 环境放心用。

首次colcon build空跑，如果成功会看到Summary: 0 packages finished。如果报错，最常见的两种是colcon: command not found（没装或没 source）和构建时提示找不到某个 CMake 包（依赖没装全）。空编译通过之后，再往里放自己的包，出问题时就容易判断是新代码引入的还是环境本来就有的。

4.3 rosdep 与依赖管理

rosdep 是 ROS 生态里专门管系统依赖的工具。你在package.xml里声明<depend>libopencv-dev</depend>，然后用rosdep install --from-paths src --ignore-src -r -y，它就会自动帮你把对应发行版的包名翻译出来并装好。这个东西不初始化，很多第三方包编译时会一直报"找不到 xxx"。

初始化分两步，rosdep init写默认配置，rosdep update拉索引。这两步在部分网络环境下会失败，一键脚本通常会帮你处理掉，可以自己验证：

rosdep --version rosdep install --from-paths src --ignore-src -r -y

某些一键脚本走得比较深，会把 ROS 系统本身的目录也纳管进 rosdep 管理范围，好处是它能帮你修复一些系统包缺失，坏处是如果哪天你想手动apt remove某个 ROS 包，可能会因为 rosdep 的记录而出现额外的确认提示。个人项目里这没什么影响，不用太在意。

4.4 可视化与调试工具

RViz2 是 ROS 2 里最重要的可视化工具，用来显示传感器数据、TF 变换、地图、点云、路径规划结果。它不是自动装的，桌面版会带上，基础版没有。验证方式是rviz2能起来，然后添加一个Grid和TF显示，能看到坐标轴就说明渲染和插件都正常。

Gazebo 用于物理仿真，跑机械臂、移动机器人、无人机的时候离不开。ROS 2 Humble 对应 Gazebo Fortress 一代，新手容易踩的坑是版本对不上导致gazebo_ros插件加载失败。用一键脚本装的话版本之间的配套关系通常已经被处理过了。

还有几个我日常必装的工具：rqt图形化工具集，用来看节点拓扑和话题列表比命令行直观；rqt_plot用来实时画曲线，调 PID 参数时非常省事；PlotJuggler用来分析录制的 bag 数据，处理几千个数据点的趋势非常流畅。这些都可以直接用 apt 装：

sudo apt install ros-humble-rqt ros-humble-rqt-common-plugins ros-humble-rqt-plot

4.5 中文输入法与终端体验

Ubuntu 22.04 和 24.04 默认用 Fcitx5 输入法框架，20.04 用的是 Fcitx4。要装中文输入，先装框架和拼音引擎：

sudo apt install fcitx5 fcitx5-chinese-addons fcitx5-frontend-gtk3

装完在"设置 - 区域与语言 - 输入源"里添加"中文（智能拼音）"，然后配置~/.xprofile或者通过 im-config 指定框架，重启后生效。常见的失败形态是"输入法切换快捷键没反应"，绝大多数情况是环境变量没配好，检查GTK_IM_MODULE、QT_IM_MODULE、XMODIFIERS三个变量是否都指向了 fcitx。

输入法这事看起来和 ROS 无关，但实际影响很大。你在 RViz2 里给坐标系命名、在配置文件里写中文注释、在 issue 里搜索中文报错，都离不开它。花二十分钟配好，后面几个月都省心。终端方面，把默认的 GNOME Terminal 换成 Terminator 或者 Tilix 会舒服很多，因为它们支持分屏，跑roscore、节点、键盘控制三个终端可以放在一个窗口里。

5. 报错排查实录：新手最常撞的八堵墙

5.1 apt 与密钥类错误

NO_PUBKEY是出现频率最高的一个。完整形态是The following signatures couldn't be verified because the public key is not available: NO_PUBKEY XXXXXXXX。原因是仓库签名公钥没导入，或者导入的位置不对。

现代做法是把公钥存成独立文件，然后在源条目里用signed-by指向它，不再往全局 keyring 里塞：

curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key \ -o /usr/share/keyrings/ros-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] \ http://packages.ros.org/ros2/ubuntu $(. /etc/os-release && echo $UBUNTU_CODENAME) main" \ | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null

还有一个高频错误是Unable to locate package ros-humble-desktop。这几乎百分之百是源没配对。逐一检查三件事：/etc/apt/sources.list.d/下有没有 ROS 相关的 list 文件、文件里的发行版代号是不是你的实际代号（22.04 是 jammy）、apt update有没有报错被跳过。

5.2 rosdep 与网络索引类错误

rosdep init报ERROR: cannot download default sources list from ...是经典问题。失败原因是它要去拉一个远程索引文件，这个请求在某些网络环境下拿不到结果。解决办法有两个方向，一是换用镜像索引，二是确认它没有因为上次失败留下了半成品文件。

后一种情况其实更常见。上一次初始化到一半失败了，/etc/ros/rosdep/sources.list.d/20-default.list已经存在，第二次执行时脚本检测到文件存在就直接报"已经初始化过"。这时候把那个文件删掉再重试，或者直接手工写好内容跳过 init 只做 update。

rosdep update卡住或者报超时，本质是拉索引列表时网络不稳定。可以多次重试，也可以配置镜像索引源。索引拉完一次之后会缓存在~/.ros/rosdep/下，正常使用不再依赖网络，所以这是个一次性成本。

5.3 Python 环境与依赖冲突

conda 和 ROS 是经典的对头。症状是编译时报ModuleNotFoundError: No module named 'empy'，但你明明刚pip install empy过。原因是你的pip装到了 conda 环境里，而colcon build调用的 Python 是系统 Python。

诊断方法很直接，看两个命令的输出：

which python3 python3 -c "import sys; print(sys.path)"

如果路径里出现anaconda3或者miniconda3，那就是问题所在。处理方式是在编译和运行 ROS 的终端里，把 conda 从 PATH 里摘出去，或者直接conda deactivate并确保没配自动激活 base 环境。

另一个坑是 PEP 668。Ubuntu 23.04 之后系统 Python 变成了"外部管理"状态，直接pip install会报error: externally-managed-environment。可行方案有三种：优先用apt install python3-xxx装系统包；确需 pip 就用虚拟环境；实在没办法再加--break-system-packages，但要清楚这有可能破坏系统工具。

5.4 仿真与图形界面问题

Gazebo 启动就崩、RViz2 白屏、终端里一堆libGL error，基本都指向图形栈。虚拟机环境下先确认 3D 加速开关打开了，显存分配够；物理机环境下检查显卡驱动是否装好，NVIDIA 用户可以用nvidia-smi确认驱动在工作。

还有一种情况是 SSH 远程连过去跑 GUI，这时候显示相关的环境变量必须正确转发，或者干脆用支持 X11 转发的终端工具。我自己的习惯是远程开发时只在本地跑 RViz2，远程机器只跑节点，用 ROS 2 的跨机通信把数据传过来，这样性能和体验都好很多，也不用折腾显示转发。

5.5 问题速查表

6. 多版本共存、卸载与重装

6.1 ROS 1 和 ROS 2 怎么和平相处

好消息是 ROS 1 和 ROS 2 的安装目录完全不重叠，一个在/opt/ros/noetic，另一个在/opt/ros/humble，文件层面没有冲突。真正会打架的是环境变量。如果你在两个setup.bash都 source 过，后 source 的那个会覆盖前面的，导致命令和库路径混乱。

处理办法就是我前面提到的别名方案，加上一条纪律：一个终端只加载一套环境。如果确实需要在同一个进程里让 ROS 1 和 ROS 2 通信，那要用ros1_bridge这个专门的桥接包，它会在两边各起一个节点做消息格式转换。这个东西配置起来不复杂但有不少细节，建议先把两边单独跑通再考虑桥接的需求。

6.2 干净卸载的正确姿势

想重装的时候，很多人直接rm -rf /opt/ros，然后发现重装之后还是一堆怪问题。因为残留的东西远不止这一个目录。

一套相对干净的清理流程是先卸包再删文件：

sudo apt remove "ros-humble-*" "ros-noetic-*" -y sudo apt autoremove -y sudo rm -rf /opt/ros sudo rm -rf /etc/ros rm -rf ~/.ros sudo rm -f /etc/apt/sources.list.d/ros*.list sudo rm -f /usr/share/keyrings/ros-archive-keyring.gpg

删完之后记得检查~/.bashrc，把之前追加的 source 语句和别名清掉。这一步很多人忘，结果是新装的版本被旧的 source 语句指向一个已经不存在的路径，每个终端开起来都报一句找不到文件。

6.3 Docker：不想折腾时的退路

如果你的宿主机系统已经乱到一定程度，或者需要在多台机器上保持一致环境，用 Docker 是更省心的方案。官方在 Docker Hub 上维护了 ROS 和 ROS 2 的镜像，直接拉下来就能跑，不会污染宿主机。

docker run -it --rm \ --network host \ -v /tmp/.X11-unix:/tmp/.X11-unix \ -e DISPLAY=$DISPLAY \ osrf/ros:humble-desktop

--network host是为了让容器里的 DDS 发现机制能正常跨机通信，不加的话节点只能在容器内部互相看见。-v /tmp/.X11-unix和DISPLAY是为了让容器里的图形界面显示到宿主机屏幕上。这两条是 ROS 容器化最容易漏的地方，漏了就是"命令能跑但 RViz2 起不来"。

7. 从装好到跑起来：新手第一周该怎么练

7.1 学习节奏安排

环境装好只是起点，接下来要有明确的推进节奏，否则很容易停留在"改改小海龟参数"的阶段。

第一天把命令行工具过一遍：ros2 node list、ros2 topic list、ros2 topic echo、ros2 topic hz、ros2 interface show、ros2 param list。这些命令配合 talker 和 listener 两个示例节点，能把节点、话题、消息、参数这几个概念建立起来。

第二天写第一个自己的节点。不用挑复杂的，做一个订阅激光雷达话题然后判断前方距离是否小于阈值并打印警告的节点，Python 二十行就能写完。重点是走一遍创建包、写代码、改 package.xml、编译、运行的完整流程。

第三天到第四天把 Launch 文件和参数文件吃透。这是从"能跑单个节点"到"能组织一个系统"的关键跨越。理解LaunchDescription、Node动作、参数传递，然后把你前两天写的节点和示例节点用 launch 文件组织起来一键启动。

第五天往后就是按你的目标方向走了。做移动机器人就学导航栈和 SLAM，做机械臂就学 MoveIt 和运动学，做仿真就深入 Gazebo 的模型和插件。这个阶段遇到问题时，你的排查能力已经比第一天强很多，因为你知道每个报错大概属于哪一层。

7.2 命令速查表

下面这些命令是我几乎每天都会用到的，建议打印出来贴在显示器边上。

7.3 一个容易被忽略的习惯

最后分享一个我自己坚持了很久的做法：每装完一套环境，就在~/notes/下写一个简短的 markdown 文件，记录这次装的是什么版本、用了哪个镜像源、遇到了什么报错、怎么解决的。看起来是个体力活，但半年后你要在另一台机器上复现或者给学弟配环境时，这份笔记的价值会立刻显现。

我就是靠着这样的记录，把一台 20.04 上的 Noetic 环境完整迁移到了 22.04 的 Humble 上，中间只花了半天。如果当时没有笔记，光是回忆"我到底改过哪些配置文件"就够头疼一整天。环境配置这件事本来就没有什么高深技巧，靠的是把每一次踩坑都沉淀成可复用的经验。