1. 先说清楚apt 到底是什么和 dpkg 是什么关系如果你在 Ubuntu、Debian、Linux Mint 这些发行版上折腾过东西大概率已经敲过apt install 软件名这个命令。但你有没有想过一个问题为什么装软件用 apt而网上有些教程却让你用 dpkg这两个东西到底谁依赖谁我当年刚开始接触 Linux 的时候也糊里糊涂直到有一次手欠去dpkg -i一个.deb包结果提示一堆依赖缺失桌面环境差点崩掉才真正搞明白它们的分工。这里先把这个底层逻辑讲清楚后面所有命令都是建立在这个基础上的。1.1 apt 和 dpkg 的分工一个是前端一个是干活的Debian 系发行版包括 Ubuntu底层包格式是.deb直接操作它的工具是dpkg。dpkg -i package.deb可以安装一个本地包dpkg -r可以卸载就这么简单。但 dpkg 有一个致命短板它不会自动处理依赖关系。什么叫依赖比如你要装一个图形界面截图工具它可能需要libpng、libglib、libgtk这些库没有这些库它根本跑不起来。如果你手动用 dpkg 装系统不会自动去拉取这些依赖你得先自己去下载所有依赖包按顺序装好。一旦装错顺序或者漏装某个库就会出现“依赖关系未满足”的报错——这就是很多人第一次装.deb包时被劝退的原因。apt 就是在这个问题上成长起来的前端工具。它会先读取包索引也就是软件源列表分析你当前系统已装了哪些包、目标包还缺哪些依赖然后自动把依赖也一起下载安装。简单来说apt 就是一个会帮你把事办妥的中间人底下的体力活还是 dpkg 在干但决策和调度都是 apt 在做。1.2 为什么日常操作优先用 apt而不是直接碰 dpkg因为 apt 解决的问题正是 Linux 软件安装里最头疼的依赖地狱。比如说你装一个包时需要同时更新某个共享库的新版本但这个共享库又被系统里其他十几个包引用把旧版本换掉会不会弄坏其他软件apt 会通过一套依赖性解析算法去评估尽量找到让所有包都能满足要求的组合。这活儿你要是用 dpkg 手动干估计半天都搞不定。另外 apt 还维护了一套包状态数据库存放在/var/lib/dpkg/status里面记录了每个包是已安装、已配置还是已卸载。dpkg --audit能看到半安装状态apt autoremove能识别哪些包是“之前作为依赖被装进来、现在不再被需要”的孤儿包。这些判断能力都是 dpkg 本身不具备的。注意我这里说的 apt 是新的 apt 命令不是老的 apt-get。Ubuntu 16.04、Debian 8 之后的系统基本都默认带了 apt。新 apt 的交互界面更好——有彩色输出、有进度条还内置了apt edit-sources这种便捷子命令。纯脚本场景下apt 和 apt-get 行为基本一致但日常手敲命令我建议只用 apt。搞清楚这个关系后面的安装、卸载、清理、换源才有讨论的意义因为每一个命令的行为背后都直接牵涉到 dpkg 数据库和依赖算法的逻辑。2. 安装软件apt install 比你想象中多做了几件事我见过不少初学者以为apt install就是把软件包下载回来解压到某个目录跟 Windows 的绿色软件似的。其实完全不是这么一回事。apt 安装一个包背后至少经过更新索引缓存、解析依赖、下载 .deb、调用 dpkg 安装、配置软件包、执行触发器这几个阶段。用apt install vim举个例子正常跑完会看到类似这样的输出Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: vim vim-common vim-runtime vim-tiny 0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded. Need to get 3,472 kB of archives. After this operation, 15.7 MB of additional disk space will be used. Do you want to continue? [Y/n]如果你只装过几次软件而没有细看这些输出建议这次认真看一眼。里面写明了哪些包会被“新安装”、总共要下载多少字节、装完会占多少磁盘空间。这行输出就是 apt 在你确认之前做好的完整计划。2.1 最常用的安装场景装一个新包最基础的用法就一句话sudo apt install 包名系统会提示要安装哪些依赖输入 Y 回车就装。如果你确定没有疑问想跳过确认步骤直接加-ysudo apt install -y vim脚本里尤其推荐-y不然自动化任务会卡在确认提示那里等人去按回车。但有个小坑-y在某些情况下会把 apt 询问“是否替换本地修改过的配置文件”这种问题的默认答案也自动带过去如果配置比较重要建议非脚本场景还是手动确认比较稳妥。如果要同时装多个包一条命令写完即可不需要分多次sudo apt install -y git curl wget htop2.2 少装推荐依赖--no-install-recommends这里是个新手几乎不会注意、但实际使用中非常影响结果的地方。Debian/Ubuntu 的包元数据里有Recommends推荐和Suggests建议这两个字段。默认情况下apt 会把 Recommends 字段里的包也一起装上。举个例子装某些桌面工具时它会顺手把一堆多媒体后端、主题包都拉进来明明你只想要个命令行工具结果系统里多了上百 MB 无关东西。这时候用sudo apt install --no-install-recommends 包名就能只装这个包和它硬性依赖的库Recommends 字段里的包一律不理。我个人会在两种场景下强制用这个参数一是 Docker 镜像里尽量减少冗余包二是机器配置较低时避免磁盘膨胀。2.3 只下载不安装、只看不自改模拟与下载模式调试环境或者离线安装场景经常需要“只下载不安装”。比如你要给另一台没有外网的机器装软件就可以在这里把 .deb 都下好再通过 U 盘带过去sudo apt install -d --no-install-recommends 包名-d是--download-only的简写所有下载下来的 .deb 会保存在/var/cache/apt/archives/里。下次想装的时候带上-o DPkg::Options::--force-confold这种参数直接使用或者更简单的方式是用apt install /var/cache/apt/archives/*.deb来从本地缓存安装。还有个好用的模拟模式先跑一遍依赖分析但什么都不动apt install --simulate 包名输出照样告诉你“会安装这些包、要下载多少兆、磁盘占用多少”但是不会真的下载安装。拿不准某个包会不会改变系统里已有组件的版本时先模拟一下再操作风险能小很多。这也是我在生产服务器上动任何软件前必跑的一步。练习建议可以找个不影响系统的包比如cowsay分别用apt install --simulate cowsay和真实安装对比一下感受输出内容之间的差异。模拟的输出和真实安装时系统给出的计划完全一致这样下次看到任何安装计划就不会只瞄一眼 Y 就回车了。2.4 安装本地 .deb 文件有时候你从官网下载了一个.deb安装包比如某些商用软件只提供官方 deb 下载。省事的方法是用apt install直接指定本地路径apt 会自动处理依赖并从软件源里补装缺失部分sudo apt install ./xxx.deb注意路径前的./不能省这是为了告诉 apt“这是个本地文件不是软件源里的包名”。这个习惯我坚持了很多年因为它比dpkg -i好用太多——dpkg 装完如果报依赖缺失你还得再手动apt install -f修复apt 一条命令把事做完了。-f也就是--fix-broken专门用来修复处于损坏状态比如依赖不满足的包这个后面会再提。3. 查询与搜索不装也能知道软件包的一切很多人习惯“搜什么装什么”但装完了才发现版本不对或者不知道装的这个包到底属于哪个软件源。其实 apt 全家桶里的查询类命令很丰富在安装之前把这些信息摸清楚能少走很多弯路。3.1 搜包名找不到包时先别慌用apt search可以在软件源索引里搜索包名和相关描述apt search 关键词比如你记不清 Nginx 的完整包名直接apt search nginx输出会列出一堆和 nginx 有关的包包括nginx-core、nginx-common、libnginx-mod-http-lua等等。每个条目前有个p或i标记i表示已安装p表示未安装。搜索范围包含包描述里的每个词所以哪怕你只知道这个软件是干什么的也有机会搜到它。如果想更精确地搜可以在关键词上加正则apt search ^nginx$这样只匹配完整包名恰好为 nginx 的包不会把nginx-core这些带出来。3.2 看详情版本、依赖、大小、来源一把梭搜索命中之后用apt show查看这个包的完整信息apt show nginx输出里你会看到 Homepage、Maintainer、依赖关系Depends、大小、软件源APT-Sources这些信息。我重点提醒三个字段Depends硬性依赖这个包能跑起来的最低要求。Version软件源里当前可获得的版本注意未必是你系统中实际的版本。APT-Sources这个包是从哪个源来的用来排查你换源之后包版本为什么还不变非常有用。看已安装包信息可以用apt show 包名也可以看apt list --installed列出所有已安装包配合grep筛选很顺手apt list --installed | grep nginx查某个具体版本能不能装用apt-cache policyapt-cache policy nginx输出会有Installed当前已装版本、Candidate候选版本即 apt 认为最适合装的版本、Version table软件源里可用的所有版本列表。这个命令在排查“为什么 apt 装不了我想装的旧版本”时特别有效。3.3 文件属于哪个包反向查询有时候你在系统里找到一个可执行文件但不知道它是哪个包装的。比如有人在你机器上装了个命令你想知道来源可以用dpkg -S $(which 命令名)或者直接查某个绝对路径dpkg -S /usr/bin/nginx这个属于 dpkg 的反向查询输出会告诉你这个文件归属于哪个包。反过来如果一个包已经被装上了你又想知道它到底往系统里写了哪些文件用dpkg -L 包名这两个命令不在 apt 里但查文件归属时几乎离不开顺带给你提个醒。心得我排查容器镜像的体积问题时会先执行apt list --installed | wc -l看看系统里一共装了多少个包再配合dpkg-query -W -f${Installed-Size}\t${Package}\n | sort -n找出磁盘占用排行前面的包。这套组合拳比单纯去翻目录强得多。4. 升级管理update、upgrade、dist-upgrade、full-upgrade 有什么区别只要有软件源包就会一直有新版本。apt 的升级命令有好几个它们名字相近作用却大不一样。很多事故恰恰是没分清楚它们之间的差异造成的。4.1 四兄弟的工作原理先看apt update。这个命令不会升级任何软件它的作用是下载软件源里的“包列表”和“元数据”也就是更新本地索引。装新包之前强烈建议先跑一次 update否则系统可能还在用上一次同步的旧索引找不到新版软件包。sudo apt update跑完之后你会看到形如Hit、Ign、Get的行。Hit表示源没变Get表示拉到了新索引Ign一般是无伤大雅的忽略项。出现错误的话会标成Err比如网络不通、源失效、签名验证失败这些问题会在后面的章节展开。然后是apt upgrade。它把系统里所有已安装的包在不删除现有包、不改变现有包依赖需求的前提下升级到软件源里可用的新版本。听起来很简单对吧但如果某个新版本的包需要额外装一个新的依赖或者新版和某个已有包发生冲突apt 就会自动跳过它并在输出里用The following packages have been kept back提示你。apt full-upgrade旧命令是apt-get dist-upgrade就不一样了它允许在升级过程中引入新依赖、移除与升级冲突的旧包。换句话说它的灵活度更高会在必要时对现有包进行删除或新增操作。所以版本跨越大版本升级比如 Ubuntu 从一个发行版升到下一个时用 full-upgrade 才能完成整个系统的演进。apt dist-upgrade和apt full-upgrade是同一个操作只是命令名的别名关系不要傻傻分两次敲。4.2 我的升级策略生产环境里我的默认做法是sudo apt update sudo apt upgrade --no-install-recommends -y不带full-upgrade。因为 full-upgrade 有可能为了升级某个包而卸载其他包这种不可控行为放在生产环境里太危险了。full-upgrade 我会在两种场合单独使用一是系统大版本升级之前二是确认版本冲突排解不了、必须允许删除共享库才能突破僵局时。另外一个非常关键的习惯先查清楚 upgrade 到底要动哪些包再看要不要执行。先跑apt list --upgradable这个命令会列出所有有可用新版本的包。看到列表后如果某个核心包比如 openssl、libc6要升级我会手动确认版本号和变更日志。知道 apt 有apt changelog 包名这个命令吗它能拉取该包的变更日志升级前扫一眼比装了新版后踩坑再回滚省事得多。如果真的升级出问题还能临时“钉住”版本不让 apt 自动升级。在/etc/apt/preferences.d/里放一个文件内容类似Package: libc6 Pin: version 2.31* Pin-Priority: 1001优先级 1001 表示强制使用这个版本apt 就不会随便动它了。日常使用中不建议钉太多包只有某些特定软件对某个库版本有严格限制时才用。5. 卸载与清理remove、purge、autoremove、clean 的区别安装只是开始软件生命周期里的另一半是卸载和清理。这个环节也是网上教程最容易误导人的地方——很多人不知道remove和purge的区别更不知道 apt 自动清理能帮你腾出多少空间。5.1 remove 与 purge配置文件也要不要删干净sudo apt remove 包名这个命令会卸载软件的主体程序但会保留配置文件、日志、用户数据。为啥要保留因为有些人的诉求是“卸载重装但配置还在”比如数据库软件或者邮件服务配置比程序本身宝贵得多。所以 remove 只删二进制和动态库普通状态文件尽量不动。如果要连配置文件一并干掉用 purgesudo apt purge 包名很多时候你卸载掉某个软件后重新装发现还是老配置老毛病就是因为之前只 remove 没 purge旧的配置文件阴魂不散。所以在排查软件问题时彻底清理应该用 purge。这两个命令也可以组合着用比如先只 remove 想保留配置后面确认彻底不用了再sudo apt purge 包名如果忘记是否还关联着其他包可以加--auto-remove把这几个命令合并处理卸载指定的同时把不再被需要的依赖也一并清掉sudo apt purge --auto-remove 包名5.2 autoremove 与孤儿依赖的清理apt 在安装软件时会把依赖库一并装进来但卸载主程序时那些依赖库不会主动跟着消失。时间一长系统里就会积累大量“没人再用”的孤立依赖。手动一个个找是不可能高效完成的这时候sudo apt autoremove它会把/var/lib/dpkg/status里标记为auto安装、但当前没有被任何手动安装包依赖的包全部清掉。注意“手动安装”和“自动安装”是有标记的apt install新装的软件是手动跟随依赖装进来的是自动。不放心可以加参数先看清单sudo apt autoremove --dry-run或者sudo apt --simulate autoremove把输出里准备卸载的包名过一遍再执行避免误伤还在用的库。重要提示无桌面环境的最小服务器每次升级后都有不少旧的 Linux 内核包被保留。apt autoremove会把旧内核也清理掉但如果你担心新内核不稳定、想保留旧内核做后备请使用sudo apt remove --purge linux-image-旧版本号手动删而不要直接全局 autoremove。我就在这上面踩过一次坑升级完内核后没确认版本就直接 autoremove旧内核全被清理后来新内核出现兼容问题想回滚发现没有可选项。5.3 clean 与 autoclean缓存文件的瘦身/var/cache/apt/archives/目录下会保留所有下载过的 .deb 包文件。如果你常年不清理这个目录可能会占用几个 GB。普通用户不会主动去看但每次apt install都会在这里累积。sudo apt clean这条命令会把下载缓存里的 .deb 文件全部删除。它不会影响已安装的软件只是腾出磁盘空间。删完缓存之后再下载唯一的缺点是重新安装某个包时要重新从网络拉取速度取决于你的带宽。如果你只想清理那些已经无法从软件源找到的 old .deb 缓存用sudo apt autoclean它只删除已经不能从当前源列表里下载的旧包缓存最新版本的缓存保留。日常维护我推荐 autoclean空间不够急需腾地方时再上 clean。这个命令对上过热搜词“you dont have enough free space in /var/cache/apt/archives/”和“c盘清理”的朋友们也有启发意义——虽然那是 Windows 的 C 盘问题但 Linux 的/var/cache/apt/archives/膨胀本质上也属于缓存清理问题。尤其是 Docker 镜像和 CI 容器里apt clean几乎是 Dockerfile 里必须有的步骤不然镜像会白白大出几百 MB。5.4 清理不只要清 apt 缓存顺带展开一句如果清完 apt 缓存还是觉得磁盘吃紧看看这些临时文件du -sh /var/cache/apt/archives du -sh /var/log du -sh /tmp日志目录如果长期不轮转也可能巨大无比配合journalctl --vacuum-size100M可以压缩 systemd 日志占用的空间。这个已经不算 apt 范畴了但做系统清理时绕不开。6. 换源与常见报错一线实操中躲不开的坑软件源是 apt 的生命线。国内直接访问官方源往往速度慢、超时多所以“换源”成了每个 Debian/Ubuntu 用户都躲不开的操作。但换源不仅仅是改个 URL 那么简单源配置稍有不对后面所有 apt 操作都会出问题。这里结合一线实操常见的报错逻辑把换源和排障的完整链路讲透。6.1 源配置文件与现代系统的新玩法老教程通常会让你直接编辑/etc/apt/sources.list。在 Ubuntu 24.04 LTS、Debian 12 及之后的版本里系统已经默认把源配置挪到了/etc/apt/sources.list.d/目录下用.sources后缀的 deb822 格式文件管理。多个源对应多个文件管理起来更清晰。举例Debian 13Trixie的.sources文件里一般长这样Types: deb URIs: https://deb.debian.org/debian Suites: trixie trixie-updates trixie-backports Components: main contrib non-free-firmware Signed-By: /usr/share/keyrings/debian-archive-keyring.gpgUbuntu 用户的/etc/apt/sources.list.d/ubuntu.sources类似但 URIs 指向的是archive.ubuntu.com那套地址。换源时最省心的一种做法是复制一份原文件出来改成国内镜像站再替换 URIs 那一行的域名。比如把http://archive.ubuntu.com/ubuntu/换成http://mirrors.aliyun.com/ubuntu/、http://mirrors.tuna.tsinghua.edu.cn/ubuntu/或http://mirrors.ustc.edu.cn/ubuntu/都可以。Debian 同理把deb.debian.org/debian换成对应镜像的路径。改完后务必执行sudo apt update这一步会重新读取所有源验证签名并拉取新的索引。如果网络和源配置无误输出会显示Get和Hit开头的行最后没有Err就说明源已经通了。6.2 常见报错排查源失效、签名错误、空间不足提示源失效或 404大概率是之前的第三方源 URL 已经不可用或者发行版某个版本已经停止维护。解决思路是用apt-cache policy或apt update输出里的错误提示定位具体是哪个源然后注释或删除/etc/apt/sources.list.d/里对应的失效文件。NO_PUBKEY 签名问题新旧系统之间遇到过很多次。表现出来是类似W: GPG error: ... NO_PUBKEY 3B4FE6ACC0B21F32这个是因为缺少某个源的 GPG 公钥。如果源本身可信比如官方镜像站、上游软件商可以安全导入sudo gpg --keyserver keyserver.ubuntu.com --recv-keys 3B4FE6ACC0B21F32然后把公钥导出到系统信任的位置。这块对于小白的门槛有点高所以我建议初学者不要随便添加第三方源老老实实用发行版自带的官方源或知名镜像源能省掉 90% 的签名排障工作量。最后是很多人在热搜里提到的关键词You dont have enough free space in /var/cache/apt/archives/这个报错在磁盘剩余空间很小的时候就会出现比如根分区只剩几十 MB。解决思路是腾出空间例如sudo apt clean清掉旧的 .deb 缓存然后也就有空间放新下载的包了。如果干净缓存后仍然不够再用du -sh /usr、du -sh /var去定位谁占大头。顺手还可以看看是不是旧内核包占得太多dpkg --list | grep linux-image把不需要的版本卸掉。提醒遇到 apt 类报错时第一件事永远是把apt update的错误完整贴出来看不要凭感觉乱敲命令。八成问题都出在“索引失效”和“空间不足”这两个方向上按顺序排查能节省大量时间。6.3 特殊场景卸载 nvidia-cuda-toolkit 这类庞然大物热搜词里有“apt 卸载 nvidia-cuda-toolkit”必须专门说一句因为你直接执行sudo apt remove nvidia-cuda-toolkit可能会发现根本没有这个包名只有nvidia-cuda-toolkit是 Ubuntu 仓库里的旧版名称在很多系统里已经改名或拆包了。正确姿势是先搜索apt search cuda-toolkit apt search nvidia-cuda找到准确的包名比如nvidia-cuda-toolkit或新的nvidia-cuda-toolkit-12-*再执行卸载。如果之前是通过 NVIDIA 官方 runfile 安装的 CUDA那就不是 apt 管的范畴了要用官方自带的卸载脚本。这个细节能帮你少走一个挺大的弯路。如果确实是通过 apt 装上来的彻底清理用sudo apt purge nvidia-cuda-toolkit sudo apt autoremove让系统把关联进来的依赖一并清掉。NVIDIA 驱动和 CUDA 工具链体积庞大这套清理下来通常能释放好几个 GB。6.4 apt 的日志回溯问题的最佳线索apt 出问题时很多人不会想到看日志。其实 apt 把每次操作都记录得很详细/var/log/apt/history.log/var/log/apt/term.loghistory.log 记录的是干了什么term.log 记录的是终端输出细节。当你不确定“系统是不是在我上次乱装包后变坏的”翻这两个日志就知道了。配合时间戳能清楚看到哪个包是在什么时候被安装、升级或删除的。这点在排查“明明没动过怎么突然报错”的时候极好用。7. 从根目录到生产环境几条管理习惯建议聊到这里apt 的主要命令基本都过了一遍安装、搜索、升级、卸载、清理、换源、排障。但真正拉开“会用”和“用得好”差距的往往是一些不起眼的习惯。最后分享几条我多年实际运维和日常使用中沉淀下来的经验。习惯一装包前先摸清家底。执行安装前至少看一眼apt show 包名和apt-cache policy 包名。特别是手动安装不确定包名的软件时这两条命令能避免装错同名包带来的连锁问题。习惯二升级前留退路。生产环境或重要开发机上执行升级前先用apt list --upgradable看清单再跑apt upgrade --simulate预演最后才实际执行。系统大版本升级前务必备份/etc/apt和/var/lib/dpkg。习惯三不要过度关闭安全更新。我看到很多人为了省事把安全更新源注释掉这是非常危险的。apt 源的security或updates通道就像软件的安全补丁通道缺失了它系统漏洞暴露的时间会大大延长。宁可升级慢一点也不要把更新通道堵死。习惯四区分手动安装与自动依赖。使用apt-mark manual 包名或apt-mark auto 包名可以手动调整包的安装标记对 autoremove 的影响非常直接。如果你不希望某个包被自动清理掉就把它标记为手动安装例如常用的apt-mark manual wget。习惯五脚本里养成固定套路。在 Dockerfile 或自动化脚本里我一般会写成apt update apt install -y --no-install-recommends 包列表 apt autoremove -y apt clean安装完立即清理依赖和缓存既能保证功能完整又不会让镜像变大太多。这条我实测下来镜像体积比不清理时通常能小 20% 到 40%差别非常明显。习惯六怀疑源被篡改时先查签名。镜像站的过渡配置偶尔会出问题apt update出现奇怪的签名错误时不要盲目跳过校验。先确认你用的源域名是否正确、系统时间是否准确——时间不对也会导致签名验证失败这一点我见过不少第一次遇到的人一头雾水。最后再分享一个小技巧当你完全不确定一条 apt 命令会造成什么影响时可以在命令前加上apt --simulate或--dry-run前缀。这些参数不是什么高深内容但它让我躲过不只一次“差点把关键依赖卸掉”的险情。多花十秒钟预演远好过拆掉后再花一个小时去修补。apt 这套命令体系虽然看起来只是“安装”“卸载”这么简单实际使用中牵扯到的依赖解析、源管理、状态标记、日志回溯每一样都值得花时间吃透。希望这篇梳理能帮你把 apt 这条链路彻底打通以后在 Debian/Ubuntu 系系统上装软件、清空间、排故障都能心里有底不靠猜。