CentOS 7 装完之后我打开终端干的第一件事几乎永远是去看/etc/yum.repos.d/这个目录。原因很直接系统刚装好那一刻默认源指向的还是境外地址yum install十有八九会转圈转到超时最后甩一句Could not resolve host或者干脆卡在那儿不动。这一步不收拾利索后面装编译工具链、装容器运行时、装 Nginx 全都得跟着卡壳一个环节堵住整条链子都动不了。repo 源管理看着是个小活儿实际上它是 CentOS 7 上所有软件安装工作的地基地基没打好后面全是返工。这篇就围绕 CentOS 7 安装之后的 repo 源管理展开把仓库文件的结构、换源的具体操作、cannot find a valid baseurl for repo这类报错的成因、恢复到默认状态的方法、断网环境下的离线安装思路以及一个容易被混淆的点——yum 的 repo 和代码管理的 repo 到底是不是一回事——全都掰开讲一遍。有一定 Linux 基础、正在维护 CentOS 7 机器的运维和开发人员可以直接抄作业刚接触 CentOS 的新手也能顺着看下来。1. 装完系统先别装软件源才是第一道坎1.1 CentOS 7 的默认源为什么这么容易出问题CentOS 7 的生命周期在 2024 年 6 月 30 日正式结束进入 EOL 状态之后官方把原本在mirror.centos.org上的软件仓库整体挪到了vault.centos.org。这个动作带来的直接影响就是大量老机器上那份从装机时就写好的CentOS-Base.repo里面配的mirrorlist和baseurl指向的地址已经不再直接提供 7 版本的软件包请求发出去要么被重定向要么直接返回 404。你在这类机器上执行yum install最典型的表现就是报Cannot find a valid baseurl for repo: base/7/x86_64或者卡在Loading mirror speeds from cached hostfile这一步迟迟不动。另一个常见诱因是镜像站本身的同步问题。国内用户默认用的是境外地址跨境访问的不确定性很大同一个地址今天能通、明天可能就超时。镜像列表mirrorlist机制本来是让 yum 从一组候选地址里挑最快的但候选地址全在境外时这个挑最快的过程本身就要花掉大量时间甚至因为网络抖动全部失败。还有一类问题来自人为改动。很多人接手一台别人装过的机器或者自己半年前折腾过源、装过第三方仓库比如 EPEL、SCL、某些商业软件的源时间一长忘了改过什么等到某次yum update突然报错才发现仓库配置里混着几份互相冲突的文件。这类问题的排查成本往往比单纯换源高得多。1.2 三类典型故障场景先对号入座我一般把 CentOS 7 的源问题分成三类处理思路完全不同。第一类是能联网但源地址失效。这是最常见的情况机器网络正常ping外网通但 yum 报Cannot find a valid baseurl。根因基本是 repo 文件里的地址过期或者被墙掉解决办法是把源换成国内可用的镜像站。第二类是根本连不上外网。典型场景是内网服务器、生产环境的隔离机压根没有出网权限。这种情况下换什么源都没用要考虑的是搭本地源或者用离线方式装软件后面第 6 节专门讲。第三类是能联网但想用特定版本。比如要装 Docker 或者某个特定版本的开发工具需要引入额外的第三方仓库docker-ce.repo、EPEL 等这时候重点不是换源而是正确地新增仓库并管理好优先级。先判断自己落在哪一类再动手比上来就一顿wget换源文件高效得多。我见过不少新手明明是内网机器还一个劲儿地换阿里云源换完照样报错然后开始怀疑人生——其实就是场景判断错了。1.3 源管理要达成的三个目标不管用哪种方案最后要达成的目标就三个一是yum makecache能顺利把元数据拉下来不报错二是yum install能正常装上软件三是这套配置在半年后别人接手时还能看懂、还能维护。第三个目标经常被忽略但它特别重要。我给自己定的规矩是改过的 repo 文件一定留备份新增的仓库文件用有辨识度的名字比如epel.repo、docker-ce.repo并在文件头用注释写清楚来源和添加日期。这花不了几分钟但能在以后排查问题时省下大量时间。源管理不只是让命令跑通更是让这套环境具备可持续维护的能力。2. 拆开 .repo 文件每一个字段都在干什么2.1 /etc/yum.repos.d/ 里到底躺着什么CentOS 7 装完之后/etc/yum.repos.d/目录下通常会有一批.repo文件最常见的几个是CentOS-Base.repo主仓库包含 base、updates、extras 这几组是日常装软件用得最多的。CentOS-CR.repoContinuous Release 仓库通常处于关闭状态。CentOS-Debuginfo.repo调试符号仓库默认关闭。CentOS-fasttrack.repo快速通道仓库一般用不上。CentOS-Media.repo本地光盘/ISO 源装机时用光盘装过系统的话会有。CentOS-Sources.repo源码包仓库默认关闭。CentOS-Vault.repo归档仓库对应 EOL 后的 vault 地址。CentOS-SCLo-scl.repo与CentOS-SCLo-scl-rh.repoSoftware Collections 相关跟centos-sclo-rh报错直接相关。这些文件里绝大多数默认是enabled0也就是不启用的。真正参与日常工作的主要是CentOS-Base.repo。理解这一点就不会被目录里文件一大堆吓到实际上需要关心的就那么一两个。提示动手改任何文件之前先执行ls -l /etc/yum.repos.d/把你看到的文件名记下来。后面万一改坏了至少知道该恢复哪些文件。2.2 一个仓库块的字段逐行解读随手打开CentOS-Base.repo里的一个块长这样[base] nameCentOS-$releasever - Base mirrorlisthttp://mirrorlist.centos.org/?release$releaseverarch$basearchrepoosinfra$infra #baseurlhttp://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7这几行的含义值得一条条讲清楚。[base]是这个仓库的 IDyum 报错时说的repo: base/7/x86_64里的base就是它。name是给人看的描述随便写都行不影响功能。mirrorlist和baseurl是二选一的关系mirrorlist指向一个返回可用镜像列表的服务yum 从里面挑一个baseurl则直接指定一个固定地址。mirrorlist更灵活但有额外开销baseurl更直接但地址失效就完全不能用。换国内源时通常是把mirrorlist注释掉、启用baseurl因为国内镜像站一般直接给固定地址速度也稳定没必要再走列表那一步。$releasever和$basearch是变量运行时会被替换成实际的版本号CentOS 7 上是7和架构x86_64。这两个变量是理解换源操作的关键——你换成国内源时改的就是这些变量背后的实际地址。gpgcheck1表示对下载的包做签名校验gpgkey指定公钥位置。这一项不要随意改成 0改了等于关掉安全检查装到被篡改的包你都不知道。2.3 变量、优先级与元数据缓存$releasever的取值来自/etc/yum.conf或者 RPM 数据库正常 CentOS 7 上就是7。如果你手动把某个源的地址写死成7.9.2009这种具体版本号就绕开了变量替换好处是地址明确坏处是以后想统一改版本号会麻烦。我个人的习惯是能用变量就用变量只在变量解析出问题时才写死。优先级priority这个机制很多人不知道。yum 本身不原生支持优先级需要装yum-plugin-priorities插件然后在 repo 文件里加priorityN数字越小优先级越高。它解决的问题是同一个包在多个仓库里都有时到底用哪个。没有优先级机制时yum 按字母序或者仓库启用顺序来挑结果不可控。元数据缓存放在/var/cache/yum/下。每次执行yum installyum 都会先检查本地缓存是否过期过期就去仓库拉新的元数据。所以换源之后一定要执行yum clean all清掉旧缓存再yum makecache重建否则可能出现源改了但 yum 还在用旧地址的诡异现象我踩过不止一次。3. 换源实操把默认源换成可用的镜像3.1 动手前的备份习惯换源的第一步永远是备份没有例外。我自己吃过这个亏某次在一台跑了很久的老机器上直接覆盖CentOS-Base.repo结果后来发现这台机器上有些内网 IP 的定制地址被我一覆盖全没了只能从别的机器上找一份回来对。备份命令很简单cd /etc/yum.repos.d/ mkdir -p backup_$(date %Y%m%d) cp *.repo backup_$(date %Y%m%d)/按日期建目录好处是多次改动后能分清哪次是哪次。别嫌麻烦这条命令两秒钟的事能救命。注意备份目录放在/etc/yum.repos.d/里是可以的因为 yum 只读.repo后缀的文件。但如果你备份时保留了.repo后缀比如CentOS-Base.repo.bak就没事CentOS-Base.bak.repo就会被 yum 读到。建议备份文件直接用.bak结尾避免被误加载。3.2 下载镜像站提供的 repo 文件换源最省事的办法是直接下载国内镜像站已经写好的 repo 文件。这里有个大家经常搜索到的命令形式curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo或者用 wgetwget -O /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo这里要特别提醒一个坑网上流传的命令里目标文件名经常被写成centos-base.repo之类五花八门的名字而下载链接又常常是截断的热搜里那种.../repo/ce结尾的地址明显是不完整的。文件名本身不影响使用但必须保证下载到的内容完整、文件名以.repo结尾。如果下载下来的文件是空的或者一坨 HTML 错误页那是因为链接错了用编辑器打开一看就知道。不同镜像站的 repo 文件略有差别常见的有阿里云、腾讯云、清华 TUNA、中科大 USTC 等。选哪个主要看你的网络到哪家的链路更好可以先curl -I测一下响应速度再决定。由于 CentOS 7 已进入 EOL很多镜像站提供的Centos-7.repo内部地址已经指向了 vault 路径比如mirrors.aliyun.com/centos-vault/7.9.2009/。这一点是正常的说明镜像站也跟着官方做了调整不用担心。3.3 手动改写 CentOS-Base.repo 的完整思路如果你不想下载别人写好的文件或者下载下来发现地址不对手动改也可以思路就是把mirrorlist注释掉、把baseurl指向可用的镜像地址。以阿里云为例改完大致是[base] nameCentOS-$releasever - Base - mirrors.aliyun.com baseurlhttp://mirrors.aliyun.com/centos-vault/$releasever/os/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled1 #released updates [updates] nameCentOS-$releasever - Updates - mirrors.aliyun.com baseurlhttp://mirrors.aliyun.com/centos-vault/$releasever/updates/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled1要点有三个一是baseurl里的路径要对os、updates、extras这几个目录名不能写错二是$releasever和$basearch变量保留让 yum 自己替换三是每个块都要有enabled1才会被启用。批量替换的话可以用 sed 一把梭sed -i s|^mirrorlist|#mirrorlist|g /etc/yum.repos.d/CentOS-Base.repo sed -i s|^#baseurlhttp://mirror.centos.org|baseurlhttp://mirrors.aliyun.com/centos-vault|g /etc/yum.repos.d/CentOS-Base.reposed 那两行的逻辑是先把所有mirrorlist行注释掉再把被注释的baseurl行启用并把地址替换成阿里云。这套替换有一个前提——你的原始文件结构与标准文件一致如果被人改过替换结果可能不对所以替换完务必cat出来看一眼。3.4 让配置生效清缓存与重建改完文件不代表生效必须清缓存、重建缓存yum clean all yum makecacheyum clean all会清掉所有缓存的元数据和包yum makecache会让 yum 按新配置重新拉一遍元数据。这一步如果顺利跑完、没有任何报错说明源配置基本没问题。想快速验证的话跑一条yum repolist它会列出当前启用的仓库和每个仓库里的包数量。如果某个仓库显示0个包或者报错跳过就要回头检查那个仓库的配置。正常情况下base、updates、extras三个都会列出来并显示包数量。4. cannot find a valid baseurl 报错全解4.1 base/7/x86_64 报错的三种成因Cannot find a valid baseurl for repo: base/7/x86_64这条报错基本是 CentOS 7 用户见得最多的一条。它出现的直接原因是 yum 拿着仓库配置里的地址去请求但没能拿到可用的仓库数据。具体成因我总结出三种第一种地址过期。EOL 之后官方地址变化老配置里的mirror.centos.org/centos/7/...不再直接提供服务请求返回错误。这是当前最普遍的原因。第二种网络不通。机器根本上不了外网或者防火墙挡了 HTTP 出向请求。判断方法是ping一下目标域名、curl -I一下仓库地址看能否拿到响应。如果连域名都解析不了那是 DNS 问题跟源配置没关系。第三种repo 文件语法错误。手动改文件时不小心把某一行写错比如baseurl拼成了baseur或者路径少了个斜杠yum 解析时找不到地址也会报这一条。这种情况用yum repolist加上-v参数能看出更多线索。把这三种可能按顺序排查——先看网络再看地址最后看配置语法——绝大多数情况十分钟内能定位。4.2 centos-sclo-rh/x86_64 的来龙去脉Cannot find a valid baseurl for repo: centos-sclo-rh/x86_64这条报错跟上面那条成因类似但它涉及的是 Software CollectionsSCL仓库来源是CentOS-SCLo-scl-rh.repo这个文件。SCL 提供的是较新版本的开发工具比如新版 gcc、Python在 CentOS 7 上常被用来装新版本语言环境。问题出在SCL 仓库在 EOL 之后也被归档了原来的地址失效于是启用 SCL 或某个软件依赖 SCL 时报这条错。处理方式有两条路一是如果不需要 SCL直接把这两个文件禁用或删掉mv /etc/yum.repos.d/CentOS-SCLo-scl.repo /etc/yum.repos.d/CentOS-SCLo-scl.repo.bak mv /etc/yum.repos.d/CentOS-SCLo-scl-rh.repo /etc/yum.repos.d/CentOS-SCLo-scl-rh.repo.bak重命名成.bak后缀yum 就不会再读它报错自然消失。二是如果确实需要 SCL那就得把这两个文件里的地址也换成可用的 vault 地址。处理思路和第 3 节一样注释mirrorlist启用并改写baseurl指向centos-vault路径下的sclo目录。改完别忘了yum clean all。提示很多时候你压根没用 SCL只是它在默认配置里被enabled1了于是每次 yum 操作都被它拖累报错。这种情况直接禁用是最省事的不需要去折腾它的地址。4.3 报错速查表把常见的源相关报错整理成一张表方便对照报错信息可能原因快速处理Cannot find a valid baseurl for repo: base/7/x86_64官方地址失效或网络不通换国内镜像源yum clean allCannot find a valid baseurl for repo: centos-sclo-rh/x86_64SCL 仓库地址失效不需要则禁用该 repo 文件Could not resolve host: mirrorlist.centos.orgDNS 解析失败检查/etc/resolv.confFailed to connect to ...: Connection timed out目标地址不通或超时换镜像站测链路repomd.xml: [Errno 14] HTTP Error 404地址路径错误核对baseurl路径Metadata file does not match checksum缓存脏了yum clean all后重试Package ... requires ...依赖在其他仓库启用对应仓库这张表不是万能的但覆盖了日常八成以上的情况遇到报错先对号入座能省不少查资料的时间。5. 把源恢复到默认状态5.1 什么时候需要回退换源这件事理论上比默认源更好用但确实存在需要回到默认状态的场景。比如接手一台机器前一位同事留了一堆来源不明的 repo 文件地址乱、包签名校验被关你不想在这个基础上继续维护干脆恢复成干净状态重新配。做某个实验需要复现官方源环境下的行为第三方镜像可能同步滞后得切回官方。repo 文件被改坏了懒得一点点修直接恢复。恢复到默认状态的做法不止一种选哪种取决于你手头有什么资源。5.2 恢复的两种路径路径一从备份恢复。如果你在换源前做了备份第 3.1 节直接从备份目录拷回来就行cp /etc/yum.repos.d/backup_20240101/CentOS-Base.repo /etc/yum.repos.d/这是最干净的恢复方式前提是有备份。路径二重新安装提供 repo 文件的包。系统默认的 repo 文件是通过centos-release这个 RPM 包安装的。如果文件被删了或改坏了可以重新装一遍这个包来还原rpm -Uvh --force centos-release-7-9.2009.1.el7.centos.x86_64.rpm yum clean all--force强制覆盖已存在的文件。这个包可以从安装 ISO 里找到或者从 vault 地址下载。恢复出来的就是原始的、指向官方现在是 vault的配置文件。路径三把已有的目录清空重来。更激进的做法是删掉所有自定义 repo 文件只保留系统自带的然后按需重新配置cd /etc/yum.repos.d/ mkdir /tmp/repo_backup_all mv *.repo /tmp/repo_backup_all/这适合那种文件太乱、不如推倒重来的情况但一定要有备份能力不然删完就抓瞎了。5.3 多源共存与优先级管理恢复或重配之后如果机器上同时启用了多个仓库比如 base、extras、EPEL、某个第三方商业源就要考虑优先级问题。两个仓库提供同一个包但版本不同时不做约束的话 yum 的选择是不可预测的。建议的做法是装上优先级插件并配置yum install yum-plugin-priorities然后在 repo 文件里加上优先级字段。经验值base/updates/extras 设为 1EPEL 设为 10第三方商业源设为 20 或更大。数字越小优先级越高这样系统的核心仓库永远优先不会被第三方源里版本混乱的包覆盖。注意优先级插件只在启用了priority的仓库之间生效没写这个字段的仓库不参与优先级比较。所以要么统一写要么统一不写别一半写一半不写。6. 断网环境怎么装东西离线安装 Docker 实战6.1 离线资源怎么准备前面说的都是能联网的场景。但生产环境里大量机器是断网的换源解决不了问题。这时候就得走离线路线在能联网的机器上把需要的软件包和依赖全部下载好拷到目标机器上安装。以搜索热词里提到的CentOS 7 离线安装 Docker为例思路是在一台和目标任务机系统版本、架构完全一致的联网机上用yumdownloader或者dnf download把 docker 相关的 RPM 包连同依赖一起下载下来。yum install -y yum-utils yumdownloader --resolve --destdir/tmp/docker-offline docker-ce docker-ce-cli containerd.io--resolve是关键词它会把所有依赖一并下载--destdir指定下载目录。下完/tmp/docker-offline里会有一堆.rpm文件打包拷到目标机器。提示离线安装最容易翻车的点就是缺依赖。下载时必须用--resolve而且联网机和目标机的系统版本、架构、已装包情况要尽量一致否则依赖对不上。我一般会在一台和目标机同源的干净虚拟机上做下载。6.2 离线安装 Docker 的完整步骤包拷到目标机器之后安装步骤如下# 进入包所在目录 cd /tmp/docker-offline # 用 rpm 一次性安装所有包 rpm -ivh *.rpm用rpm -ivh *.rpm一次性装的好处是如果依赖不满足rpm 会一次性把所有缺失依赖的报错都列出来而不是像一条条装时那样装到一半卡住。看到缺什么补什么即可。装完之后验证systemctl start docker systemctl enable docker docker versiondocker version能打印出客户端和服务端版本就说明装好了。如果不用 RPM也可以用官方提供的静态二进制包static binary tarball解压后把docker可执行文件放到/usr/bin/再手动配 systemd 服务。这种方式对系统依赖更少适合包管理极其受限的环境但配置稍麻烦需要自己写 service 文件。6.3 搭一个本地离线源机器数量多的时候一台台拷包太累更优雅的做法是在内网搭一个本地源。有两种常见形式。用 ISO 挂载做源。把 CentOS 7 的安装 ISO 传到服务器上挂载后配置一个指向本地的 repomkdir /mnt/centos-iso mount -o loop /path/to/CentOS-7-x86_64-DVD.iso /mnt/centos-iso然后写一个/etc/yum.repos.d/local-iso.repo[local-iso] nameLocal ISO baseurlfile:///mnt/centos-iso enabled1 gpgcheck0挂载 ISO 得到的包是有限的它只包含基础系统包不包含 updates 里的更新。所以这种方式适合装机后装一套基础软件不适合装全量更新。用 createrepo 搭 HTTP 源。把需要分发的所有 RPM 集中到一个目录用createrepo生成元数据再用 Nginx 或 Apache 暴露出去yum install createrepo mkdir -p /var/www/repo/custom cp /path/to/*.rpm /var/www/repo/custom/ createrepo /var/www/repo/custom/客户端只要配一个指向这台服务器 HTTP 地址的 repo 文件就能像用公网源一样装包。这是内网环境的常规做法一次搭建长期受益。createrepo在 RPM 包有更新时记得重新跑一遍否则客户端拉到的还是旧索引。7. 别搞混yum 的 repo 和代码管理的 repo 是两码事7.1 两者本质区别搜索repo时经常还会撞到另一个概念代码仓库管理里的 repo。这两个 repo 名字一样但完全是两回事第一次接触的人很容易搞混。yum 的 reporepository软件仓库指的是软件包的存放和分发位置是一堆 RPM 包加上描述它们的元数据yum 从这里下载并安装软件。它解决的是软件从哪来的问题。代码管理的 repo指的是基于 git 的多仓库管理工具Android 源码就是用 repo 管理的它本身是一个 Python 脚本用来在多个 git 仓库之间做统一的操作比如一次性拉取、同步、提交几十上百个 git 仓库。它解决的是几十个 git 仓库怎么统一管的问题。一句话区分一个管软件包一个管代码仓库。名字撞车纯属巧合。7.2 git 与 repo 工具的取舍如果真要谈代码管理工具git 和 repo 的关系值得说清楚。git 是基础管理单个仓库分支、提交、合并这些概念都来自它。绝大多数项目用 git 就够了。repo 建立在 git 之上专为一个超大项目拆成很多个 git 仓库的场景设计典型代表是 Android 和 Chromium 这种代码量巨大的项目。它的优势是一次命令能同步所有子仓库还能用 manifest 文件精确锁定每个子仓库的版本。劣势也很明显学习成本更高日常小项目用它纯属杀鸡用牛刀而且它依赖 Python 环境版本升级有时会带来兼容问题。所以选择上单仓库或少量仓库的项目直接 git只有像 Android 那样几十上百个仓库协同的场景才值得上 repo。至于网上偶尔提到的repo 中文补丁那是给 repo 工具做界面语言本地化的东西跟源管理没有半点关系搜索时注意区分语境。8. 实操心得与避坑清单8.1 常见问题速查把这篇文章里散落的经验汇总成一张速查表方便动手时对照场景建议操作关键注意换源前备份/etc/yum.repos.d/用日期建目录备份文件用.bak后缀下载 repo 文件核对链接完整、内容非空别用截断的地址手动改文件注释 mirrorlist启用 baseurl变量保留路径要对改完生效yum clean all yum makecache必须清旧缓存验证yum repolist每个仓库应有包数量SCL 报错不需要则禁用.repo文件改名.bak即可恢复默认从备份恢复或重装 centos-release恢复后清缓存多源共存装 priorities 插件并配 priority要么全写要么全不写离线安装yumdownloader --resolve系统版本架构要一致内网本地源ISO 挂载或 createrepo HTTP更新后重建元数据8.2 我个人踩过的几个坑最后分享几个我实际踩过、文档里基本不会写的坑。坑一换了源但忘了清缓存。症状是我明明换成阿里云了怎么还报原来的错。原因就是旧的元数据缓存还在yum 优先用了它。记住yum clean all是换源动作的一部分不是可选项。坑二备份文件被 yum 读到。有次我把备份命名成CentOS-Base.repo.old以为没问题结果 yum 把它也加载了导致两个仓库 ID 冲突报already exists。后来统一改成.bak后缀就再没出过这问题。yum 判断文件是靠后缀不是靠内容。坑三在错误的机器上准备离线包。在一台 CentOS 7.6 上下载的包拿到 7.9 的机器上装个别依赖版本对不上装到一半失败。离线安装的黄金法则是让准备机和目标机尽可能一致实在不行就装一台和目标机同版本的虚拟机专门用来下包。坑四忽略 gpgcheck 的后果。图省事关掉签名校验当时是能装上包了后来一次安全审计直接被打回来所有关掉校验的仓库都得恢复。gpgcheck 关起来容易恢复起来要一个个仓库重新确认公钥特别麻烦。能不关就别关。坑五优先级混写。一部分仓库写了priority一部分没写结果优先级完全没按预期生效包版本还是乱的。后来全部统一配上优先级才稳定。这个机制的坑点在于它不会报错只是静默地不生效非常隐蔽。源管理这件事说起来都是些命令和文件的活儿但真正做顺手靠的是对每个文件、每个字段、每条报错的理解以及一套稳定的操作习惯。CentOS 7 虽然已经 EOL但大量存量机器还在跑把这些基础的东西理清楚后面无论换到哪个发行版思路都是相通的。