在 Debian/Ubuntu 系中安装软件怎么选更省空间？

📦 各包管理方式的磁盘占用机制

⚡ APT / dpkg：共享依赖，基础占用最小

APT 是 Ubuntu 的底层包管理器，安装 .deb 包。其核心优势在于依赖库全局共享：多个应用依赖同一个系统库（如 libc、openssl）时，系统中只存一份，所有应用共用。

安装前，APT 会明确预估所需空间：

1
Space needed: 8149 kB / 1328 MB available

若加上 --install-suggests，同样的 Apache2 安装，所需空间从 8.1 MB 激增至 34.1 MB。这直观展示了依赖链的“连锁膨胀”效应。

APT 的磁盘占用构成：

APT 缓存是容易被忽视的空间消耗点。轻度使用系统缓存约几十 MB 到几百 MB，而频繁安装/更新的开发机可能积累 数 GB 的 .deb 缓存。使用 sudo apt clean 可彻底释放，sudo apt autoclean 则仅清理已过期版本。

小结：APT/dpkg 的安装后实际占用最小，因为依赖全局共享，没有冗余。主要可回收空间来自缓存目录。

🔒 Snap：依赖全量打包，旧版本堆积严重

Snap 由 Canonical 主导，每个 Snap 包自带所有依赖和运行时环境，不依赖系统库。这带来了跨发行版的便携性，但代价是磁盘占用显著增大。

典型体积对比：Firefox 的 Snap 版本约 200 MB，而对应 DEB 版本仅约 70 MB。

Snap 最突出的空间问题在于旧版本保留机制：默认保留每个应用的 3 个旧版本（含当前活跃版本）。有用户发现近 8 GB 空间被旧 Snap 版本占用；VS Code 的 Snap 版本甚至因未清除已删除文件而“吞噬”数 GB 存储。

Snap 的空间占用分布：

清理 Snap 旧版本需手动操作：查看占用用 du -sh /var/lib/snapd/snaps/*，删除指定旧版本用 sudo rm /var/lib/snapd/snaps/包名_版本.snap（仅删非活跃版本）。

小结：Snap 的首次安装体积较大，且旧版本自动堆积是持续性的空间隐患。服务器场景若完全移除 Snap，可回收约 800 MB 根分区空间。

🧩 Flatpak：运行时共享，优于 Snap 但仍高于 APT

Flatpak 采用运行时（Runtime）共享机制：多个应用若使用同一运行时（如 org.gnome.Platform），则该运行时在磁盘上只存一份，应用之间共享。这与 Snap“每个应用自带一切”的模式有本质区别。

但 Flatpak 的首次安装仍然较重。以 GIMP 为例：

• • AppImage：约 164 MB
• • 系统包管理器（APT）安装后：约 366 MB
• • Flatpak（应用 + 运行时）：约 797.6 MB

运行时占用是主要开销。曾有报告显示 Flatpak 的 runtime/ 目录占用高达 11.8 GB，repo/ 目录占用 10.8 GB。不过随着应用数量增加，运行时的边际成本递减：安装第一个 GNOME 应用需下载完整 GNOME 运行时，后续同类应用则复用同一运行时，额外空间很小。

Flatpak 的空间回收要点：

1
2
3
4
5
# 查看应用与运行时占用flatpak list --app --columns=name,size# 清理未被任何应用使用的运行时flatpak uninstall --unused

[3†L11-L13]此外，Flatpak 的 repo/objects/ 目录可能积累大量小文件碎片，有用户报告清理了 20 GB 的冗余数据。

小结：Flatpak 的首次安装开销大，但得益于运行时共享，多应用场景下的总占用优于 Snap。定期运行 flatpak uninstall --unused 是必要的维护操作。

📁 AppImage：自包含单文件，体积可控但难以共享

AppImage 将应用及其全部依赖打包为单个可执行文件，运行时通过 FUSE 只读挂载，不修改系统目录。其磁盘占用特点：

• • 单文件体积：常见为几十 MB 到数百 MB，取决于捆绑的依赖库数量。简单工具可能仅 2–6 MB，复杂应用（如视频编辑器）经压缩后仍可能达数十 GB 量级。
• • 无共享机制：每个 AppImage 独立打包依赖，多个 AppImage 之间无法共享库文件，若安装多个应用，总占用会线性叠加。
• • 清理简单：删除 .AppImage 文件即完成卸载，无残留配置（除非应用自行在用户目录创建数据）。

以 GIMP 为例，AppImage 约 164 MB，小于 Flatpak 的 797.6 MB，但可能大于 APT 仓库安装体积（366 MB），具体因应用而异。

小结：AppImage 的单次占用中等，适合偶尔使用的独立工具。但大量安装时空间效率最差，因为完全无法共享依赖。

📊 磁盘空间占用综合对比（往左滑动表格）

💎 节省磁盘空间的实践建议

优先选择 APT 安装。 若软件在 Ubuntu 仓库中有 .deb 版本，始终优先使用 APT。依赖共享机制从根本上避免了冗余存储，且缓存可一键清理。

若需 Snap，必须管理旧版本。 定期运行 du -sh /var/lib/snapd/snaps/* 检查，手动删除非活跃旧版本。服务器上如不使用 Snap，可考虑完全移除 snapd 以回收空间。

使用 Flatpak 时，控制运行时数量。 尽量让应用使用同一运行时（如统一 GNOME 或 KDE 平台），并定期执行 flatpak uninstall --unused。避免安装多个不同运行时版本的同类应用。

AppImage 仅用于临时或低频场景。 不要将其作为主要安装方式。若确需多个 AppImage，优先考虑改用 Flatpak 或 APT 版本以利用共享机制。

善用分析工具定位空间消耗。 使用 ncdu 或 baobab 扫描 /usr、/var/lib/snapd、/var/lib/flatpak 等目录，快速定位大体积包和残留文件。

核心结论：从节省磁盘空间的角度，APT/dpkg 是绝对的最优选择；Flatpak 在容器化方案中空间效率较好，适合桌面应用较多的场景；Snap 的空间开销最大且维护成本高；AppImage 则适合“用完即走”的轻量使用模式。