企业官网建设流程全解析

新装好一台机器，或者刚把系统装进虚拟机，第一件事往往是打开终端敲命令装软件。结果经常会遇到这样的情况：apt-get install某个包，回车之后等半天，最后来一句E: Unable to locate package，包名明明没拼错，社区文档里也写得清清楚楚。这时候但凡有经验的人都会说一句：你先sudo apt-get update一下。这条命令短得像一句咒语，几乎每个 Linux 用户都敲过成百上千次，但真要说清楚它到底干了什么、为什么不敲它装不上软件、update和upgrade差在哪、sudo在中间又扮演什么角色，能完整讲明白的人其实不多。我见过太多人把它当成“开机仪式”，无脑执行，出了报错就复制粘贴去搜，搜到的答案又大多是“换源”“重装系统”这种大锤方案。这篇内容就把sudo apt-get update这条命令从里到外拆一遍，讲清楚三个单词各自负责什么、背后走了哪条链路、索引文件落在磁盘哪个位置、签名校验怎么绕过会出事、非交互环境下为什么它会抱怨“需要一个终端”，以及我自己在真机和虚拟机里踩过的那些坑。不管你是刚接触 Linux 命令的新手，还是天天写自动化脚本但没深究过 apt 工作原理的老手，应该都能从里面捞到点东西。

1. 一条 update 命令，为什么值得单独拆开讲

1.1 从“包明明存在却装不上”说起

E: Unable to locate package xxx这个报错，几乎是所有 Linux 新手遇到的第一道坎。它的字面意思是“找不到这个包”，但真实情况往往不是包不存在，而是你本地的“软件包清单”太旧，甚至压根就是空的。刚装完的系统，/var/lib/apt/lists/目录里几乎是空的，apt 没有任何关于仓库里有哪些包、什么版本、依赖关系如何的信息。这时候你去 install，它当然找不到。

这个机制很像去一家大型超市买东西。超市货架上确实有货，但你手里拿的是一张几年前的旧商品目录，目录上没印这个新商品，你自然就认为超市没有。apt-get update干的事情，就是去超市重新拿一份最新的商品目录回来，而不是把货架上的货搬回家。理解了这一点，你就能明白为什么这条命令执行起来那么快——它只是下载几个索引文件，并不是真的在下载软件包本体。很多人误以为“更新”就是升级系统，所以不敢随便敲，怕把系统搞坏，这个误解得先纠正过来。

还有一类更迷惑的情况：你在公司的内网环境里，源指向的是内部仓库，外网根本连不上，update一跑就是一排超时和失败。这时候问题不在命令本身，而在源列表指向的地址是否可达。所以“包找不到”这件事，往下追至少有两个分支：本地索引过期，或者索引根本拿不到。分清楚这两类，排查方向完全不同。

1.2 sudo、apt-get、update 三个词各自负责什么

把这条命令切成三段看，每个部分的职责非常清晰。sudo解决的是“谁有资格干这件事”，apt-get是“用哪个工具干”，update是“干什么”。

sudo的全称是 superuser do，作用是临时以另一个用户（默认是 root）的身份执行命令。为什么更新软件源需要提权？因为索引文件写在/var/lib/apt/lists/，这个目录普通用户没有写权限；软件源配置文件在/etc/apt/下面，同样属于系统配置区域。apt 在设计上就把“修改系统级软件状态”这个动作划归为特权操作。这和数据库里改表结构需要更高权限是一个道理，属于权限边界设计，不是故意为难人。

apt-get是 Debian 系包管理工具的前端命令行接口，后面还有真正的底层工具dpkg在干活。apt-get 负责解析依赖、和仓库对话、下载 deb 包；dpkg 负责把 deb 包真正解包安装到文件系统上。apt命令是后来推出的更友好的前端，输出带进度条和颜色，日常手敲更舒服，但脚本里依然推荐用apt-get，因为它的输出格式更稳定，不会因为版本变化突然改提示文字。

update这个子命令，官方描述是“从仓库同步软件包索引”。注意用词是同步索引，不是升级软件。这三个词组合起来，完整含义就是：以管理员权限，用 apt-get 工具，去各个配置好的仓库地址，把最新的软件包索引同步到本地。三个部分缺一不可，sudo去掉会权限不足，apt-get换成别的工具行为可能不同，update换成upgrade就是另一件事了。

1.3 和数据库里的 update、Windows 的 update 不是一回事

这个词的歧义值得单独提一句，因为它真的误导过不少人。在 SQL 里，UPDATE是修改数据行的语句，影响的是业务数据；在 Windows 里，Windows Update 是系统打补丁、升级系统组件的机制，动的是操作系统本身。而 apt 语境下的update，动的是本地的“包目录缓存”，既不修改已安装的软件，也不改任何业务数据，纯粹是一次元数据同步。

正因为语义差别这么大，很多刚从前两个场景转过来的人会把apt-get update当成“升级系统”。于是要么不敢执行，要么执行完了以为系统已经升级到最新，实际上一个包都没动。正确的对应关系是：apt-get update相当于刷新目录，apt-get upgrade才是按目录把有新版的东西升级上去。

把这三个语境分开之后，再看命令本身就不会有心理负担了。sudo apt-get update是一次只读性质为主的操作——它向仓库发起请求、下载文件、写本地缓存，对已安装软件的状态零改动。这也是为什么各种自动化脚本、容器构建流程里，第一步几乎毫无例外都是它，因为它安全、幂等，重复执行不会把系统搞坏。真正需要谨慎对待的是后面那两步，这个在后面章节会展开讲。

2. 命令执行链路：从回车到索引落盘

2.1 sudo 这一层：权限、校验与认证缓存

敲下回车之后，第一个接手的是sudo。它会做几件事：先查当前用户是否在/etc/sudoers或/etc/sudoers.d/目录下的规则里被授权，然后检查是否需要输入密码，最后以目标用户身份启动子进程。默认情况下，sudo 的密码认证结果会缓存一段时间，通常配置是 5 分钟，也就是说你刚输过密码，5 分钟内再敲 sudo 命令不会再问。缓存策略里还有一个tty_tickets选项，意思是每个终端会话单独计票，你在 A 终端认证过，换到 B 终端还得重新输。这个设计是为了防止一个会话被劫持之后，其他地方跟着遭殃。

sudo 的规则文件千万别用普通编辑器直接改，而是要用visudo。原因是 visudo 会在保存前做语法检查，发现写错了会拦住你。手改/etc/sudoers写出语法错误的后果相当严重——sudo 直接罢工，你可能连修它的权限都没有了，只能进单用户模式救援。我自己早期就干过这事，多打了一个逗号，结果整个 sudo 不可用，折腾了半小时才恢复。所以规则写进/etc/sudoers.d/目录下的独立文件是更稳的做法，出问题删掉那个文件就行，主文件不会被污染。

另外要理解的一点是，sudo apt-get update里的sudo只影响这一条命令，不会把你整个 shell 变成 root。命令执行完，权限就交还了。这和sudo -i进入一个 root 交互式 shell 完全不同，后者会让后续所有命令都跑在 root 身份下，风险大得多。日常操作建议保持“用到才提权”的习惯，不要图省事开一个 root shell 挂在那里。

2.2 apt-get 这一层：源列表是怎么被读出来的

sudo 通过校验之后，apt-get 正式启动，它要做的第一件事是确认“去哪儿拿索引”。这些地址来自两个地方：主配置文件/etc/apt/sources.list，以及目录/etc/apt/sources.list.d/下所有以.list或.sources结尾的文件。现代发行版越来越倾向于把第三方源拆成独立小文件放在sources.list.d里，好处是增删一个源不用动主文件，管理起来清爽。

源列表每一行的格式是这样的：先是类型标记deb（二进制包）或deb-src（源码包），然后是仓库地址，接着是发行版代号，最后是组件名。以常见的写法为例，代号可能是jammy、bookworm这类名称，组件通常是main、restricted、universe、multiverse这样的分类。这里每个字段都有作用：代号决定了 apt 去仓库的哪个子目录找文件，组件决定了拉哪些分类的索引。写错代号是最常见的翻车点之一，比如把代号写成了版本号，apt 会直接报 404，因为仓库里根本没有那个路径。

比较新的发行版还支持一种叫 deb822 的格式，写在.sources文件里，长这样：

Types: deb URIs: http://example.com/debian Suites: bookworm Components: main contrib Signed-By: /usr/share/keyrings/example.gpg

这种格式字段清晰，不容易因为空格数量写错而解析失败，还支持一行配多个类型。如果你维护的源比较多，建议逐步迁移到这种格式，可读性和容错性都更好。

调试方面有个特别实用的参数：apt-get update --print-uris。它会把你即将访问的所有地址打印出来，但不会真的下载。源配置有没有生效、拼写对不对、走的是哪个地址，一眼就能看出来。这个技巧我强烈建议记住，比盲猜快得多。

2.3 update 这一层：索引文件到底下载了什么

地址解析完之后，apt 开始逐个仓库拉取索引。核心文件包括仓库的Release或InRelease文件，里面有仓库的元信息和各索引文件的校验值；然后是Packages索引，压缩形式通常是.gz或.xz，里面列出了这个仓库所有包的名称、版本、依赖关系、文件大小、校验和。如果配置了源码包，还会有Sources索引。此外还有翻译文件，也就是描述信息的多语言版本。

这些文件下载下来之后，先放在/var/lib/apt/lists/partial/这个临时目录，全部校验通过才会移动到/var/lib/apt/lists/下面，文件名会被改写成带仓库地址特征的长名字。这个“先临时后转正”的机制是一个典型的安全设计：如果下载中途断了、文件不完整，apt 不会用半截数据去覆盖已有的可用缓存。你在报错信息里看到partial这个词，多半就是下载没完成。

正因为索引文件本身也不小，一个完整配置的仓库拉下来，几十兆是很正常的，所以第一次update会比较慢，之后就快多了，因为 apt 会检查文件是否有变化，没变化就不重新下载。这也解释了为什么“刚装完系统第一次 update 特别慢，后面重复执行几乎瞬间完成”这个现象。

想直观看看本地缓存长什么样，可以执行：

ls -lh /var/lib/apt/lists/

你会看到一堆名字很长的文件，每个对应一个仓库的某个索引。看这些文件的时间戳，就能判断上次同步是什么时候。如果某个源的文件时间戳明显偏旧，说明那个源可能一直拉取失败，只是报错被淹没在滚动输出里没注意到。

2.4 签名校验：为什么换个源会冒出 NO_PUBKEY

索引下载之后不是直接就用，apt 会验证仓库的数字签名。流程大致是：仓库用私钥对Release文件签名，apt 用本地存有的公钥去验证，验证通过才信任这个索引里的内容。公钥存放在/etc/apt/trusted.gpg.d/和各个 keyring 文件里。这套机制防的是“中间有人偷偷把索引换掉，塞进来一个假的包”这种情况。

一旦你新加了一个第三方仓库，本地没有对应的公钥，apt 就会报NO_PUBKEY并拒绝使用这个源的索引。这时候需要把仓库提供的公钥导入本地。老的教程会教你用apt-key add，但apt-key在较新的发行版里已经被标记为废弃，原因是它把密钥加到全局信任区，任何仓库都能用这个密钥验证，安全性太差。现在推荐的做法是把密钥单独存成一个文件，然后在源配置里用signed-by指定：

sudo curl -fsSL https://example.com/key.gpg -o /usr/share/keyrings/example.gpg

然后在源里写deb [signed-by=/usr/share/keyrings/example.gpg] ...。这样这个密钥只对这个仓库生效，互不干扰，也不会污染全局信任。这个细节很多教程还没更新，照着老教程做虽然也能跑起来，但等哪天发行版彻底移除 apt-key，那些配置就全废了，不如一开始就用新姿势。

还有一类报错叫Release file is not valid yet，字面意思是发布日期还没到。这听起来很荒谬，实际原因通常是本机系统时间不对，比如虚拟机从休眠恢复之后时间漂移了，导致本地时间比仓库文件的签名时间还早。遇到这种情况别急着折腾源，先看一眼系统时间，用时间同步服务校准一下往往就好了。

3. 动手实操：把更新流程做成一套可复用的动作

3.1 第一步：备份源列表，再谈替换

不管你是新装机器还是想换源，动手之前先备份，这是铁律。命令很简单：

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo cp -r /etc/apt/sources.list.d /etc/apt/sources.list.d.bak

备份的意义在于，一旦换了源之后出现各种奇怪问题，你能一键退回到可用状态，而不是在一堆报错里手忙脚乱地往回改。我见过太多人换源换出问题之后，连原来写的是什么都不记得了，只能重装系统。有了备份，sudo cp回来再update一次就恢复原状，前后不到一分钟。

换源时的选择原则其实很简单：选一个到你这台机器网络路径短、响应稳定的镜像。判断方法不是看别人推荐，而是自己测。可以先用--print-uris看看当前访问的地址，然后用curl -o /dev/null -s -w '%{time_total}\n'去测几个候选地址的响应时间，谁快用谁。这个动作花不了两分钟，但能省掉后面每次 update 的等待时间。

还要注意的一点是版本代号必须和你的系统匹配。用lsb_release -cs或者读/etc/os-release里的信息确认当前代号，写源的时候一字不差地抄进去。代号写错是新手换源最常见的翻车原因，症状就是 update 报一堆 404，而源本身其实是好的。

源文件改完之后立刻执行一次sudo apt-get update，看输出有没有Err或者W开头的行。全绿才说明配置正常，有黄色警告就要看一眼是什么，别直接忽略。特别是签名相关的警告，当时不处理，等到真正装包的时候会突然失败，很难定位。

3.2 第二步：update、upgrade、autoremove 三步走

搞清楚这三步的分工，日常维护就有了固定套路。我的习惯是固定这个组合：

sudo apt-get update sudo apt-get upgrade sudo apt-get autoremove

第一步刷新索引，第二步把所有已安装且可升级的包升到该仓库提供的最新版本，第三步清理因为依赖关系变化而变成“孤儿”的自动安装包。三步之间的顺序不能颠倒，先 update 后 upgrade 是硬性要求，因为 upgrade 依赖 update 拉下来的最新索引来判断哪些包有新版本。

upgrade和dist-upgrade（新命令叫full-upgrade）的区别也值得记一下。upgrade只做“不改变依赖关系”的升级，如果某个包的升级需要新增或删除其他包，它会选择跳过。full-upgrade则允许增删包来完成升级，处理内核版本变更这类情况时更彻底，但风险也更高，因为它可能删掉一些你认为重要的东西。日常打补丁用upgrade就够，跨大版本升级才需要动full-upgrade，而且升级前一定要读清楚它会删掉哪些包。

autoremove这一步容易被忽略，但它对保持系统整洁很重要。装软件时 apt 会自动装上依赖，卸载主包时这些依赖默认留在系统里，时间长了就是一堆没人用的库。autoremove会把它们清掉。保险起见可以先加--dry-run跑一遍看清单：

sudo apt-get autoremove --dry-run

确认里面没有你还需要的东西，再去掉参数真正执行。这一步我吃过亏，某次它列出来的东西里有个手动装过但没标记为 manual 的包，直接执行就被一起清掉了。所以先干跑一遍这个习惯，值得养成。

3.3 第三步：让 update 跑得更快的几个开关

索引文件里有一块是翻译文件，也就是软件包描述的本地化文本。默认情况下 apt 会尝试拉取这些文件，但如果你只用命令行看英文描述，它们纯属浪费带宽。可以在 update 时关掉：

sudo apt-get update -o Acquire::Languages=none

这一个开关在源仓库翻译文件多的时候，能明显减少下载量。想永久生效就把这行配置写进/etc/apt/apt.conf.d/下新建的文件里，格式写成Acquire::Languages "none";，以后不用每次带参数。

重试策略也值得调一下。默认重试次数不多，网络稍微抖一下就失败了。可以这样：

sudo apt-get update -o Acquire::Retries=3

另外还有一些针对连接的调优项，比如并发连接数、单文件超时时间，这些参数在网上能查到，但我要提醒一句：调优之前先确认瓶颈在哪。如果瓶颈是本地网络到镜像的链路质量，再怎么调参数也没用，换个更近的镜像收益更大。我见过有人花一下午调各种 apt 参数，最后发现问题只是源地址指向了一个很远的地方。

还有一个容易被忽略的点：如果你的机器同时配了多个源，而且这些源里包含大量重复内容，update 的时间会是线性累加的。定期检查sources.list.d目录，把不用的源文件删掉，是最简单也最有效的提速方式。

3.4 非交互环境下的 sudo：免密码与 -S 的取舍

有一类报错几乎每个搞自动化的人都遇到过：在脚本、定时任务或者某些图形化工具里调用 sudo，终端返回一句提示，大意是“需要终端才能读取密码”。这个报错的成因很直白：sudo 默认从终端读取密码，而在没有 TTY 的环境里，它无处可读，只能报错退出。

应对方式有几种，各有各的适用场景。第一种是从标准输入喂密码，用-S参数：

echo 'yourpassword' | sudo -S apt-get update

这招在临时脚本里能用，但把密码明文写在脚本里是明确的安全隐患，只适合一次性调试，别落到长期维护的文件里。第二种是配置免密码，在/etc/sudoers.d/下新建一个文件，用visudo -f编辑：

youruser ALL=(ALL) NOPASSWD: /usr/bin/apt-get update

注意这里我把授权范围限定到了具体的一条命令，而不是写成NOPASSWD: ALL。后者意味着这个用户执行任何命令都不需要密码，一旦账户被利用，后果是全面的。最小授权原则在这里体现得最明显：需要免密的操作有多少就放多少，多一个字符都是风险。

第三种是配置requiretty相关选项，让 sudo 在无终端时也能工作。这个选项在不同发行版里默认值不一样，老版本默认要求有 tty，新版本多数已经调整。改它之前要清楚自己在放宽什么限制，别只是为了让报错消失就随手改掉。

关于免密码，还有一点经验之谈：如果只是为了避免重复输密码，先看看 sudo 的认证缓存时间是不是够用。默认 5 分钟，日常操作其实够，频繁被问密码往往是操作间隔太长。真正需要免密的场景是无人值守的自动化，那种场景下更要严格控制授权范围。

3.5 没网也能更：离线环境下的包更新思路

内网机器、隔离环境、气隙网络里的机器，update是跑不通的，因为它本质上是个联网操作。这类场景的思路是“在有网的机器上把东西准备好，再搬过去”。

最基础的方式是用apt-get download单独下载某个包：

apt-get download nginx

它会把 deb 文件下到当前目录，不安装。把这堆 deb 拷到目标机器，用dpkg -i或者apt-get install ./*.deb安装。这里有个关键点：apt-get download只下载指定的包，不会连带下载它的依赖。你需要在有网环境里把依赖链一起理出来，否则拷过去装不上还是要来回折腾。

更完整的做法是在有网机器上把包缓存目录整体保留下来。apt 下载过的 deb 会存在/var/cache/apt/archives/，定期执行apt-get install --download-only可以在不安装的情况下把包和依赖全部下到缓存里，然后打包整个目录搬到目标机器，配置一个本地文件源指过去。这套流程搭一次麻烦，搭好之后可复用，适合长期的离线维护场景。

还有一种方式是配置局域网内的镜像服务，把外网源同步到内网服务器上，内网机器统一指向这台服务器。这个方法前期投入最大，但对多台机器的环境来说最省事，索引同步一次，所有机器受益。搭建的时候注意同步策略，别把全量仓库都拉下来，几百 G 的空间很容易就吃满了，按需选择组件和架构即可。

4. 报错排查速查：把常见故障对号入座

4.1 权限与终端相关报错

权限类报错的特征非常明显：提示里出现Permission denied、Are you root?这类字眼。最直接的原因就是漏了 sudo。有些命令看着人畜无害，比如apt-get update，实际需要写系统目录，所以必须提权。判断方法很简单，看它要写的路径属于谁，属于 root 的就老老实实加 sudo。

另一类就是前面提过的终端问题，报错信息里会出现“a terminal is required”这类表述。前面已经讲了成因和几种解法，这里补充一个排查顺序：先确认当前环境有没有 TTY，用tty命令看输出是不是not a tty；再确认 sudoers 里有没有针对这个用户的免密规则；最后检查是否有requiretty这类限制。按这个顺序走，基本都能定位到。

还有一种容易被误判成权限问题的情况：文件存在但被锁住了。典型报错是Could not get lock /var/lib/dpkg/lock-frontend。这不是权限不足，而是有另一个 apt 进程正在运行，占着锁。常见触发场景是系统自带的自动更新服务在后台跑，或者你上一条 apt 命令还没结束就开了第二个终端。处理方法先别急着删锁文件，先看看是谁占着：

ps aux | grep -i apt

确认没有活跃进程之后，再考虑锁文件是否因为异常退出而残留。直接删锁文件是最后的兜底手段，不到确认进程真的死了别用。

4.2 源、网络与 DNS 相关报错

这类报错的表现是 update 输出里出现Err行，后面跟着具体域名和错误原因。Temporary failure resolving指向 DNS 解析失败，先查/etc/resolv.conf里的解析服务是否可用，用ping或者getent hosts试一下域名能不能解析出来。如果域名解析正常但连接超时，那就是网络可达性问题，检查路由、防火墙策略，看目标地址的端口是否被拦。

404 Not Found通常意味着源地址或版本代号写错了。这种报错会把完整的 URL 打出来，对着 URL 逐段检查，通常能一眼看出问题在哪。常见错误是把代号写成了别的版本名，或者组件名写了仓库不提供的分类。Hash Sum mismatch则是下载下来的文件校验值对不上，原因可能是中间网络设备改写了内容，也可能是本地缓存脏了。处理方法是清掉缓存重新拉：

sudo rm -rf /var/lib/apt/lists/* sudo apt-get update

清缓存这个操作要谨慎，因为它会把所有源的索引都删掉。但如果已经报校验错误了，说明现有缓存本来就不可信，清掉重建是合理的。清完之后立刻 update，中间不要执行安装操作，否则会因为找不到包而报另一个错。

4.3 锁文件、缓存与依赖相关报错

依赖类报错发生在安装阶段，比如unmet dependencies，意思是某个包需要的依赖没能满足。这类问题的成因通常是源里缺少对应的包，或者版本不匹配。排查思路是先看报错里点名了哪个依赖，然后用apt-cache policy 包名看本地索引里有没有这个包、有哪些版本可用。如果索引里就没有，说明当前配置的源覆盖不到，需要补源。

缓存相关的报错还有一个隐蔽的分支：磁盘满了。/var/cache/apt/archives/会随着下载不断增长，某些系统上这个目录可能被塞满，导致后续操作失败但报错信息不含“磁盘”字样，让人摸不着头脑。用df -h看一眼根分区使用率，再用du -sh看看几个缓存目录的大小，能快速排除这类问题。清理方式就是前面提的 autoremove 和 clean 组合。

apt-get clean会清空整个下载缓存目录，apt-get autoclean只清理已经用不到的旧版本包。后者更温和，日常维护用后者就够了，前者适合确定不再需要离线安装包的场景。这两个命令和autoremove的分工也不一样：前两个清的是下载缓存文件，autoremove清的是已安装但不再需要的包。

4.4 一张常见报错对照表

把上面这些整理成一张表，遇到问题直接对号入座会快很多：

这张表覆盖不了所有情况，但日常遇到的八九成问题都在里面。超出这张表范围的报错，建议先仔细读一遍完整输出，apt 的报错信息其实写得挺具体，只是经常被一屏滚动带过去没人看。

5. 容易被忽略的细节和我踩过的坑

5.1 定时更新与并发锁

给服务器配置自动更新是个常见需求，但直接往 crontab 里塞一条 apt 命令很容易出问题。核心风险是并发：自动更新正好在你手动执行 apt 的时候跑起来，两边抢锁，轻则报错，重则把一个事务打断在中途。稳妥的做法是用flock加文件锁：

flock -n /var/lock/apt-update.lock sudo apt-get update -qq

-n表示拿不到锁就直接退出，不等待，这样两次任务重叠时后来的那次会安静退出，不会互相干扰。日志方面建议把输出重定向到独立文件，别让它往系统邮件里塞，时间长了邮箱日志会很难看。

还有一点是时间选择。自动更新如果安排在业务高峰期，磁盘 IO 会被拉高，尤其是之后跟着跑 upgrade 的时候，解包和写文件的压力不小。放在凌晨的低峰时段，配合日志轮转，是比较省心的组合。-qq参数可以显著减少输出，日志文件不会迅速膨胀到几百兆。

5.2 磁盘空间与索引清理

前面反复提到缓存目录会增长，这里具体说下我自己的清理节奏。每周跑一次apt-get autoclean清掉过期的包缓存，每月跑一次autoremove --purge清理孤儿包，每季度看一眼/var/cache/apt/archives的总大小。这套节奏在一般用途的机器上能保持根分区稳定，不会因为缓存堆积而报警。

需要提醒的是，autoremove --purge带 purge 会把配置文件也删掉，如果某个服务你卸载了但想保留配置方便以后重装，就别带这个参数。配置是否保留这种决定，最好在执行前用--dry-run看一遍清单再决定，别等删完了再想办法恢复。

另外，/var/lib/apt/lists目录虽然存的是索引，占用空间也不小，但别没事就删。删掉之后所有 install 操作都会失败，直到你重新 update。只有在缓存校验出错这类明确场景下才清理它，而且清完立刻重新拉取。

5.3 几条我自己的经验

第一条是关于源的粒度。我早期习惯把所有需要的仓库都写进主 sources.list，后来发现管理起来很乱，加一个删一个都要动主文件。现在全部拆成sources.list.d下的独立文件，每个文件对应一个来源，文件名带上用途，比如内部仓库一个文件、第三方工具一个文件。出问题时删对应的文件就行，主文件永远保持干净。

第二条是关于报错的阅读习惯。apt 的输出信息量很大，真正有用的往往只有那几行E:开头的，但它们夹在几十行下载进度里。养成先把输出重定向到文件再挑关键行的习惯，比滚动翻找高效得多：

sudo apt-get update 2>&1 | tee /tmp/apt-update.log grep -E '^(E|W|Err)' /tmp/apt-update.log

第三条是关于“先 update 再报错”这个动作本身。我现在遇到任何 apt 相关的诡异问题，第一步都是先跑一次 update，确认索引是最新的，再去看问题是否还在。相当一部分所谓“bug”，在索引刷新之后就自己消失了，因为根本原因就是本地索引过期。这个动作成本极低，把它放在排查流程的最前面很划算。

最后一条是关于记录。每次动了源配置、加了密钥、改了 sudoers，我都会在一个纯文本笔记里记一行，写清楚改了什么、为什么改、怎么回退。这类配置改动往往隔几个月才需要再动一次，到时候凭记忆是绝对想不起来的。别小看这一行笔记，它能省掉你至少一次重装系统的时间。