Ubuntu 18.04已经停止维护很久了但手头的老服务器、旧笔记本上跑着的系统并不会因此自动消失。凡是还在用这个版本的人十有八九都遇到过同一个问题apt update慢得让人怀疑人生或者干脆报错——不是连不上官方源就是安全更新仓库解析失败。我这个月恰好整理了一台还在跑生产业务的老机器从头把换源这件事完整走了一遍这里就把整个流程和踩过的坑原原本本记录下来。先说结论把源换成清华镜像源之后这台机器上sudo apt update的时间从原来的两分多钟降到了二十秒左右日常安装软件包的下载速度也有了几倍的提升。如果你手头也有这样一台吃灰的 Ubuntu 18.04或者正在帮同事收拾历史遗留环境这篇文章基本可以让你照着敲命令就能完成一次干净利落的换源操作。我尽量把每一步的背后原因、验证方法以及我实际遇到过的各种报错都写清楚省得你来回搜索浪费时间。1. 为什么Ubuntu 18.04的老系统优先考虑换源1.1 官方源在18.04上的体验问题Ubuntu 默认使用的软件源地址是archive.ubuntu.com和security.ubuntu.com这两个域名背后的服务器部署在海外放在北美和欧洲的数据中心里。国内网络访问这类跨境节点延迟和丢包是绕不开的现实问题。最直接的感受就是每次跑apt update的时候进度条经常卡在某个百分比不动或者明明带宽看着挺大下载速度却只有几十KB每秒要命的是还会频繁超时重试。另外还有一个特殊情况18.04 的五年标准支持周期在2023年就已经走完了。之后官方把这类版本的核心仓库内容冻结新的安全更新不会再通过源仓库推给所有用户部分镜像节点也可能逐渐清理掉旧版本的目录。这种情况下如果你保持默认的官方源配置apt update偶尔会出现类似 The repository ... is not signed 或者 404 Not Found 的错误本质上是上游源本身发生了变化不是你系统坏了。1.2 清华镜像源为什么是国内方案的优先选择镜像源这个概念的通俗解释就是某个组织把上游的软件仓库整体同步一份放到自己的服务器上用户下载软件包时不用再跨越物理距离去访问原始服务器直接访问离自己最近的同步服务器。生活类比一下你本来要专门跑一趟国外超市买菜路上堵车、还经常缺货现在小区门口开了一家分店货架上的商品和总店完全一致你当然优先去分店。清华镜像源在国内开源软件圈子里的地位比较特殊它有几个我自己比较看重的特点同步频率高和上游仓库的偏差通常比较小踩到这个包在官方源里有、镜像里没有这种问题的情况比较少。接入带宽充足实际使用中跑满家用宽带或者机房带宽都是常有的事。支持 HTTPS 访问在配置层面和官方源切换几乎没有成本。对 Ubuntu 18.04 这类已经 EOL 的旧版本镜像站仍然保留相应的归档目录至少能让你完成一次干净的环境修复。当然国内还有不少其他镜像站比如部分电商云厂商、高校实验室维护的开源镜像它们的质量也都不错。你完全可以举一反三只要理解了本文的操作套路把域名替换成其他任何一个镜像站都一样。我之所以反复推荐清华源只是因为它在我实际环境里表现最稳定这也是我带团队时一直沿用下来的默认方案。2. 动手之前先把这三项确认完换源本身只是改一个文本文件看起来没什么技术含量但我在帮别人远程处理问题的时候见过太多改了源还是不行的案例。拆开分析十有八九是动手之前没有把系统基本状况搞清楚。所以在真正执行替换之前我强烈建议你先花两分钟把下面三件事确认一遍。2.1 确认当前系统和apt版本别看这步简单出错率反而最高。很多人自己机器上装的其实不是标准版 Ubuntu而是某个深度定制的衍生发行版甚至是基于测试通道的系统只不过lsb_release输出的信息看起来很像标准版。你要是没确认就盲目把源改成 bionic18.04 的代号轻则apt update报一堆404重则因为依赖版本不一致直接把系统搞得半残。确认系统版本用的是最简单的一行命令lsb_release -a输出里的Codename字段如果是bionic那才是真正的 Ubuntu 18.04。顺便看一眼内核版本uname -a如果内核版本号是 4.15 或者 5.4 之类的旧内核基本可以判定是标准环境。另外我还习惯看一下 apt 本身的版本apt --versionUbuntu 18.04 自带的 apt 版本是 1.6 左右这个版本的 apt 对仓库配置的解析逻辑和后来的版本没有根本差异但如果你在系统上手动装过新版 apt某些源配置文件的写法可能不太兼容。这个概率虽然低确认一下总没错。2.2 确认网络能不能正常解析和连接换源前先做个网络连通性测试能帮你把源的问题和网络的问题分开。很多用户换完源发现apt update依然慢或者报错最后查出来是 DNS 解析失败或者机房防火墙挡了外网连接。这种情况跟你用哪个镜像源没有任何关系。先测试解析ping -c 3 mirrors.tuna.tsinghua.edu.cn如果 ping 不通但你的浏览器可以正常打开网站可能是 ICMP 协议被禁这种情况不用管。如果域名完全无法解析可以先把 DNS 临时切到公共 DNS 再试一次。Ubuntu 18.04 用的是systemd-resolved临时测试可以直接修改/etc/resolv.conf但要注意这个文件可能是指向 systemd 链接的改之前最好先确认一下。接着测试仓库地址本身是否可访问curl -I http://mirrors.tuna.tsinghua.edu.cn/ubuntu/dists/bionic/Release如果返回的是200 OK说明镜像服务的根路径正常。这一步非常重要因为很多人没有意识到镜像站的路径是有固定格式的你见过那种 URL 拼接错误导致 404 的配置吗反正我见过不少。2.3 确认源文件里面现在到底写了什么默认的sources.list内容通常包括archive.ubuntu.com、security.ubuntu.com以及可能的deb-src行。有一个细节我之前没有特别注意但后来帮别人排查问题时发现很坑如果这台机器以前被人改过源比如已经换成了某个内网代理、某个云厂商源那么你直接看默认文件内容判断当前状态很容易误判。所以执行命令前一定要先看一眼cat /etc/apt/sources.list如果文件内容已经不是最初的官方源那么你后面的 sed 替换命令就不能盲目执行否则可能出现新旧地址混写的情况。正确做法是先备份然后直接写一份全新的标准内容。这正是我在下一节里要讲的核心步骤。3. 完整换源步骤可直接照抄换源的操作整体可以分成三件事备份、替换、刷新。下面每一步我都会解释为什么这样做以及如果跳过会有什么后果。3.1 第一步备份源文件改任何系统配置文件之前先做备份这不是胆小是基本的操作纪律。系统配置文件出了问题最痛苦的不是没法修而是不知道原来的正确状态是什么样。你留一份.bak备份哪怕改坏了一分钟就能恢复回来。sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak备份完了可以顺带确认一下文件属性不至于后续操作把文件名搞错ls -l /etc/apt/sources.list*3.2 第二步将镜像地址替换为清华镜像这里有两种做法我分别说一下适用场景。如果你是第一次换源源文件还是官方默认状态那么用命令行的 sed 批量替换是最快的方案。Ubuntu 18.04 的默认源包含两类域名软件仓库域名和安全更新仓库域名。两条命令分别把它们指定为清华镜像sudo sed -i shttp://.*archive.ubuntu.com/ubuntuhttp://mirrors.tuna.tsinghua.edu.cn/ubuntug /etc/apt/sources.list sudo sed -i shttp://security.ubuntu.com/ubuntuhttp://mirrors.tuna.tsinghua.edu.cn/ubuntug /etc/apt/sources.list注意这里我用了作为分隔符而不是常见的/。因为 URL 本身包含斜杠如果用/做分隔符你需要在替换内容里加一堆转义符命令看起来又乱又容易写错。这是文本处理里的一个小经验但排查起来相当省时间。另外如果你用 HTTPS 地址或者源文件里写的是https://命令里的匹配模式需要相应调整。我给的命令只匹配http://开头的地址如果你的源文件里写的是别的协议先手动看一眼再执行。如果你发现源文件已经被改过、内容乱七八糟或者你希望彻底脱离历史包袱那我建议老老实实把文件清空后重写。用你熟悉的编辑器打开sudo vi /etc/apt/sources.list清空后粘贴如下内容。这是我在 18.04 环境上验证过可直接使用的最小完整配置包含了主仓库、更新仓库、安全更新仓库和扩展仓库deb http://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse deb http://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse deb http://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse deb http://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse不要被网上一些教程带偏觉得一定要添加deb-src行。deb-src对应的是源码包普通用户日常根本不下载源码编译加上这些行不仅增加apt update时的索引时间还会因为部分源码目录同步不完整导致报错。我自己的原则是不需要源码编译就坚决不加。还有一个小细节Ubuntu 在源列表里经常会有partner仓库里面放的是第三方闭源软件这个仓库已经很久没有实质更新了清华源上也未必完整保留。所以我没有把它列在基础配置中保证干净稳定优先。3.3 第三步刷新软件包列表修改完配置文件以后执行sudo apt update这个命令会重新拉取软件源仓库中的包索引。如果你的网络环境是干净的清华镜像的带宽优势这时就能直接体现出来了。刷新的过程中屏幕会滚动大量软件包列表信息最后几行如果出现Get:16 http://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-security/universe Translation-en [56.0 kB] ... Reading package lists... Done说明这次换源已经成功了。我建议你接下来再验证一下实际效果sudo apt-cache policy输出里每个仓库的候选版本信息如果是500配置就没问题。再安装一个小软件包试试sudo apt-upgrade 之前先做一次严格来说apt upgrade不是必须的但如果你的机器很久没有更新过换源之后做一次升级其实是对新源文件内容的一次整体校验。如果源配置有问题通常在升级过程就会暴露出来。3.4 关于HTTPS安全更新的一个注意事项提到安全更新仓库我必须补充一个重要细节。清华镜像源上 Ubuntu 仓库的根路径是/ubuntu/18.04 的安全更新并没有使用独立的域名目录而是走了bionic-security这个分类路径。这一点和后面章节里提到的 20.04、22.04 略有不同。因此我们写的源配置里security 相关内容直接指向http://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security ...是正确且稳妥的。曾经有网友把security.ubuntu.com的路径和清华源的路径混写结果apt update报了各种 404问题就出在这里。4. 换源后常见的五个问题和排查方法换源这件事本身不难但换完之后的路未必一帆风顺。我把实际支持中遇到频率最高的五个问题整理成一个速查性质的表格然后在后面逐条展开说明遇到哪一个都能快速对上号。问题现象最常见原因快速解决方法apt update提示无法解析域名DNS 配置异常检查/etc/resolv.conf临时切到公共DNS测试更新时提示 Hash Sum mismatch本地缓存损坏或网络中间层篡改清空 apt 缓存重新 update提示 Release file expired系统时间不准用 ntpdate 同步时间提示 The repository is not signed源文件缺少公钥或索引过期更新密钥、删除对应 lists 缓存更新软件时报 404 错误镜像站没有同步该包等待镜像同步或临时换用另一镜像4.1 DNS解析与连接超时问题换源后如果直接报Could not resolve mirror...或者Temporary failure resolving...问题基本都在 DNS。Ubuntu 18.04 的默认网络管理方式是systemd-resolved/etc/resolv.conf往往是一个指向 systemd 生成的符号链接。你手动改完 DNS 之后重启一下systemd-resolved才能真正生效sudo systemctl restart systemd-resolved测试解析时不要只ping域名还要结合curl抓取真实 HTTP 状态码。很多机房的网关是禁 ping 的但 HTTP 访问正常你要是一直等 ping 的结果容易误判成网络不通。4.2 缓存导致的 Hash Sum mismatch 问题Hash Sum mismatch是我个人踩过最多的一种报错。它的产生逻辑是apt下载索引文件后用本地缓存的哈希值和服务器返回的哈希值做比对如果不一致就会拒绝使用这个索引。常见诱因有两个。第一个是本地/var/lib/apt/lists/目录下残留了上次不完整下载的缓存文件第二个是网络中间有代理服务器或者运营商缓存对 HTTP 响应做了改动。解决办法也比较固定sudo rm -rf /var/lib/apt/lists/* sudo apt clean sudo apt update清掉重来绝大多数情况下都能解决。只有极少数场景是镜像站本身同步出了问题这时候换个镜像源验证一下就能把问题定位清楚。4.3 Release文件过期与系统时间偏差Release file for ... is expired这类报错表面看起来像是源仓库过期了实际上多半是本地系统时间不对。源服务器上的 Release 文件带有时间戳apt会校验这个时间戳是否在可接受时间范围内。如果你的系统时间比真实时间晚了好几天甚至几个月apt会以为所有文件都过期了。检查系统时间date如果确实不对用 ntpdate 同步一下sudo apt install ntpdate -y sudo ntpdate ntp.aliyun.com同步完成后再执行apt update就会正常。严格说这是老问题但 18.04 这类老系统特别容易出现cmos电池耗尽、时间重置的情况所以我把这个排障项放在前三位。4.4 与第三方PPA和自定义源的兼容问题很多人在用 18.04 的时候会额外安装一些第三方软件仓库比如某些开发工具的官方源、某个语言运行时维护者的源。这些第三方源的地址五花八门而且部分并不提供 HTTPS甚至部分仓库在 EOL 之后已经停止维护。这时候你换的清华源本身没问题但只要运行apt updateapt 仍然会去访问所有已启用的仓库。如果其中一个第三方仓库已经失效整个apt update流程也会报错。虽然这不影响清华源的基本功能但会给你的判断造成干扰。如果你确认不需要第三方源最干净的做法是把/etc/apt/sources.list.d/目录下的自定义源文件重命名禁用sudo mv /etc/apt/sources.list.d/custom.list /etc/apt/sources.list.d/custom.list.disabled然后再跑一次apt update。如果恢复正常说明问题确实出在第三方仓库上。如果确认是某个你想保留的仓库那就单独修改它的源地址而不是因为看到报错就整个禁用。4.5 更新时提示 404 Not Found换源之后下载某个具体软件包时报 404通常是因为清华镜像站没有实时同步到这个包。镜像站的同步是周期性任务上游刚发布的新版本或者某个冷门包不一定在所有镜像节点都完整保留。尤其对于已经 EOL 的系统上游冷门包的归档状况更难保证。遇到这种问题我一般建议不要在一条路上死磕。临时切换一个备用镜像源其他高校镜像或云厂商镜像验证一下是不是镜像同步差异。如果是那就等一下或者调整同步周期。还有一种情况是架构问题源里的包分amd64、i386、arm64等多个架构如果你的系统架构特殊而镜像站没有同步对应架构目录也会报 404。这种情况最好直接用dpkg --print-architecture查一下当前架构类型。5. 换源前后的实际改善效果5.1 感受最明显的几个数据项我用同一台机器在相同网络环境下分别测了换源前后的表现。需要提前说明这个测试结果会受到机器所在网络环境影响不一定代表所有用户但方向性完全可以参考。测试项换源前官方源换源后清华镜像源执行apt update总耗时2分15秒左右22秒左右下载100MB软件包的平均速度约300-800KB/s约8-20MB/s过程中出现的超时/重试次数经常出现3次以上基本为0报错概率偶尔 404极少这里面的差距并不是因为清华镜像的服务器性能高出官方源多少倍而主要是网络路径变短、丢包率降低带来的连锁效应。TCP 传输协议在高延迟高丢包环境中即使带宽足够实际吞吐量也会被大幅压低。你把服务器从境外挪到国内物理延迟从几百毫秒降到几十毫秒TCP 的滑动窗口和拥塞控制立刻就能释放真实网速。5.2 感受比较深的稳定性收益换源之后我感受最深的其实不只是速度快而是稳定两个字。官方源在高峰期经常出现的半途断流明显少了apt update一次性跑完的概率大大提高。这在实际运维中很影响心情一次源更新中断可能不会立刻损坏系统但会破坏索引缓存下次再做任何包管理操作你都可能面对各种奇怪的状态。另外清华镜像站提供了比较完整的元数据和签名信息18.04 这种老系统在官方源已经不那么上心的阶段从镜像站拿到一致性更好的索引数据对保持系统可维护性是有实际意义的。它不能帮你解决 EOL 带来的所有兼容问题但至少能保证系统日常的包管理操作不因为仓库不可达而瘫痪。6. 给还在用18.04的人的一些实际建议写到这里我额外补充一批基于个人长期维护老系统总结出来的经验它们不一定属于换源的直接操作范畴但对你后续整体稳定性很有帮助。第一点换源解决的是访问速度和仓库可达性问题它没有办法让 EOL 系统重新获得官方安全支持。如果你这台机器只是在内网做开发、测试不直接暴露到公网风险是可控的。但如果涉及公网服务尽快规划升级到仍然受支持的 LTS 版本才是根本出路。第二点即使换完了源也要建立最小改动心态。老系统的软件环境往往牵一发动全身不要贪多求全一次性apt upgrade几百个包。如果非要升级先做好快照或者至少完整备份。第三点我在实际操作中还养成了一个习惯换源之后顺手把/etc/apt/sources.list.d/里每个自定义源文件的启用状态都检查一遍。这样做的原因是后续每次apt update遇到问题你能第一时间缩小范围而不是每次都被某个隐藏的第三方源打断节奏。第四点如果你有容器化运行环境优先考虑把应用迁移到容器里而不是继续在裸露的老系统上不断打补丁。换源只是让老系统活得舒服一点真正的长治久安还得靠架构层面升级。最后分享一个小技巧换完源之后我习惯先执行一次sudo apt --download-only dist-upgrade这个参数只下载软件包而不实际变更系统。它既验证了新源索引的可用性又不会因为一次性升级太多包而引入意外变更。实测下来这个习惯帮我躲过好几次因为网络中断导致的问题。
的KM算法BFS模板：从顶标到增广全解析)
