sudo apt install 包名首选:自动依赖、统一升级、干净卸载,由发行版维护。
约 1486 字大约 5 分钟
2026-05-14
同一个软件,往往有好几种装法:包管理器一键装、下载官方二进制、自己编译源码、用语言包管理器装。它们在“好不好维护、升级方不方便、依赖谁管”上差别很大。这篇帮你在装之前就想清楚“该用哪种方式”,而不是装完才后悔。
对比包管理器安装、预编译二进制、源码编译、语言包管理器四种方式,知道各自的取舍,按场景选对装法。
sudo apt install 包名首选:自动依赖、统一升级、干净卸载,由发行版维护。
curl -LO 下载地址 && tar -xf 包下载现成可执行文件,拿来即用,但升级要自己来。
./configure && make && sudo make install自己编译,最灵活也最难维护,非必要不用。
pipx install 包名装某个语言生态的工具或库,与系统软件分开管理。
| 方式 | 优点 | 代价 | 适合 |
|---|---|---|---|
| 包管理器 | 自动依赖、统一升级、干净卸载 | 版本可能偏旧 | 系统服务、常用工具——默认首选 |
| 预编译二进制 | 拿来即用、版本新 | 升级、卸载全靠自己 | 包管理器里没有、或要特定新版的工具 |
| 源码编译 | 最灵活、可定制编译选项 | 要装编译环境、依赖自己扛、维护成本高 | 确实需要定制,且你愿意长期维护 |
| 语言包管理器 | 贴合语言生态、版本管理好 | 只解决该语言的依赖 | 项目的代码依赖、语言写的命令行工具 |
能用 apt install / dnf install 解决的,就用它。原因在 包管理器总览 讲过:自动依赖、统一升级、干净卸载。它唯一的“缺点”是版本可能比上游慢半拍——但对绝大多数系统服务和工具来说,稳定 > 最新。
只有当“包管理器里没有”或“自带的版本太旧、确实满足不了需求”时,才考虑其他方式。
很多工具(尤其是 Go 写的)直接发布预编译好的可执行文件,下载解压就能用:
curl -LO https://example.com/tool-linux-amd64.tar.gz
tar -xf tool-linux-amd64.tar.gz
sudo mv tool /usr/local/bin/ # 放进 PATH 里的目录放 /usr/local/bin 是惯例——它在 PATH 里,又和包管理器管理的 /usr/bin 分开,不会冲突。代价是:包管理器不知道这个程序的存在,以后升级、卸载都得你自己手动来,也不会自动收到安全更新。
./configure && make && sudo make install 是最“原始”的方式。它最灵活,但代价也最大:要装一整套编译工具链、依赖库要自己找齐、装到哪、怎么升级、怎么干净卸载,全是你的事。除非你确实需要定制编译、且愿意长期维护,否则别走这条路。
pip、npm、cargo 这些适合装语言生态内的东西。一个常见的好实践是:用 pipx 装 Python 写的命令行工具——它会给每个工具单独建隔离环境,不会污染系统 Python,也不和 apt 装的东西打架。但别用 pip install 去装本该 apt 管的系统组件。
非包管理器安装的东西,要自己记得它的存在
用二进制或源码方式装的软件,游离在包管理器的管理之外——它不会被 apt upgrade 升级,不会自动打安全补丁,dpkg -L 也查不到它。后果是:半年后你可能完全忘了它是怎么来的、怎么升级。建议:① 优先用包管理器;② 不得已用二进制时,记录下载地址和版本;③ 装来路不明的二进制或 curl | bash 脚本前,先确认来源可信、看清脚本内容(见 sudo、su 与 root)。
| 误区 | 更稳妥的做法 |
|---|---|
| 觉得包管理器版本旧,一律自己编译 | 稳定通常比最新重要,优先包管理器,旧到不够用再考虑其他 |
| 二进制随手丢一个目录就完事 | 放 /usr/local/bin,并记下来源和版本,方便日后升级 |
用 pip install 装系统级组件 | 语言包管理器只管项目依赖,系统工具用系统包管理器 |
把网络脚本直接管道给 bash 装 | 先下载、看内容、确认来源,再决定是否执行 |
版权归属:Shuo Liu