Ubuntu服务器版必做：安装后第一时间删snapd，运维都在这么干

一、运维集体踩坑！Ubuntu预装的它，正在拖垮你的服务器

Ubuntu服务器版凭借稳定、易用、生态完善的优势，早已成为运维圈的“首选系统”，无论是个人开发测试，还是企业级部署，都能看到它的身影，甚至撑起了Linux服务器领域的半壁江山，帮无数运维节省了系统搭建的时间成本。

但很少有人知道，每次全新安装完Ubuntu服务器版，系统里都会偷偷预装一个“隐形拖油瓶”——snapd，它看似是辅助软件安装的工具，却被无数资深运维当成“首删目标”。更让人疑惑的是，有人说删了它服务器能提速30%，也有人警告“乱删会搞崩系统”，到底谁才是对的？

其实不止普通运维，就连常年和服务器打交道的老兵，都曾被snapd坑过：业务高峰时它擅自自动更新，占用大量内存导致服务中断；明明没装几个软件，却被它占走好几G磁盘空间；甚至有运维因为没及时删它，出现软件依赖冲突，熬夜排查到凌晨。

为什么运维们对snapd如此“深恶痛绝”？安装完Ubuntu服务器版，到底该不该第一时间删它？删了之后真的能让服务器更稳定吗？今天就一次性说透，看完再也不用踩坑。

关键技术详解：snapd到底是什么？开源免费吗？

snapd是Ubuntu背后Canonical公司推出的一款软件管理工具，本质是Snap包管理框架的核心守护进程，初衷是解决不同Linux版本的软件兼容性问题——它会把软件和所有依赖库打包在一起，不用手动折腾依赖，理论上能让软件安装更简单快捷。

从开源属性来看，snapd本身是开源免费的，无需支付任何费用，其相关的snapcore软件、snapcraft.io前端界面，均对外开放源码，任何人都能查看和修改。但它的核心命脉——软件商店后端服务器，却是闭源私有，这也为后续的争议埋下了隐患。

在GitHub上，snapd相关开源项目星标累计达数万，凭借Ubuntu的强大影响力，一度成为Linux通用包管理的热门选择，也确实帮不少新手解决了“软件安装依赖报错”的痛点，但在服务器场景下，它的弊端却被无限放大。

二、核心拆解：一步不差，教你安全删除snapd（附报错解决）

首先要明确一点：对于Ubuntu服务器版用户来说，删除snapd完全安全，不会影响系统核心功能——因为服务器的核心需求是稳定运行服务，而snapd并非系统必备组件，大部分服务器场景下，我们用APT包管理就能满足所有软件安装需求。

以下操作步骤适配Ubuntu 20.04、22.04、24.04、26.04等主流服务器版本，全程用终端命令操作，每一步都有详细说明，复制就能执行，新手也能轻松上手，同时同步常见报错的解决方法，避免删错搞崩系统。

第一步：查看已安装的Snap软件（确认删除范围）

删除snapd前，需先查看系统中已通过Snap安装的软件，避免直接删除snapd导致依赖冲突，终端输入以下命令：

snap list

执行后会显示所有Snap软件列表，通常默认预装的有core20、lxd、snapd等，比如以下示例（不同版本略有差异）：

root@ubuntu2204:~# snap listName    Version        Rev    Tracking       Publisher   Notescore20  20240416       2318   latest/stable  canonical✓  baselxd     5.0.3-80aeff7  29351  5.0/stable/…   canonical✓  -snapd   2.63           21759  latest/stable  canonical✓  snapd

snapd默认会后台运行，直接删除会提示“服务正在运行”，需先停止并禁用其相关服务，终端输入以下命令（一次性执行）：

systemctl disable snapd.service && systemctl disable snapd.socket && systemctl disable snapd.seeded.service

删除时需注意：列表中“Notes”列标注为“base”的软件（如core20），是其他Snap软件的依赖项，必须放在最后删除，否则会报错。终端输入以下命令，逐个删除软件（替换软件名为列表中实际名称）：

# 先删除非依赖软件（如lxd）sudo snap remove --purge lxd# 再删除依赖包（如core20）sudo snap remove --purge core20# 最后删除snapd本身sudo snap remove --purge snapd

若软件较多，可使用脚本批量删除，终端输入以下命令创建并执行脚本（自动循环删除所有Snap软件）：

# 创建脚本文件cat > remove_snap_package.sh << EOF#!/bin/bashsnap remove --purge lxdsum=\$(snap list | awk 'NR>=2{print \$1}' | wc -l)while (\$sum -ne 0); dofor p in \$(snap list | awk 'NR>=2{print \$1}'); do snap remove --purge \$pdonesum=\$(snap list | awk 'NR>=2{print \$1}' | wc -l)doneEOF# 赋予脚本执行权限chmod +x remove_snap_package.sh# 执行脚本bash remove_snap_package.sh

脚本执行完成后，若提示“ No snaps are installed yet. Try 'snap install hello-world'. ”，说明所有Snap软件已删除干净。

第四步：彻底删除snapd并清理残留（避免后续自动重装）

删除Snap软件后，需彻底卸载snapd工具，并清理其残留文件，避免系统后续自动重装，终端输入以下命令（依次执行）：

# 彻底卸载snapdsudo apt autoremove --purge snapd -y# 清理残留文件和目录sudo rm -rf ~/snapsudo rm -rf /snapsudo rm -rf /var/snapsudo rm -rf /var/lib/snapdsudo rm -rf /var/cache/snapd# 锁定snapd，防止自动重装sudo apt-mark hold snapd

删除过程中，很多人会遇到报错，无需慌张，以下是3种最常见报错的解决方法，复制命令就能搞定：

1. 报错“error: cannot remove "core20": snap "core20" is not removable: snap is being used by snap lxd.”

# 原因：依赖包被其他软件占用，先删除占用它的软件（如lxd），再删除core20sudo snap remove --purge lxdsudo snap remove --purge core20

2. 报错“Waiting for conflicting change in progress...”（更新冲突）

# 第一步：按Ctrl+C结束当前操作# 第二步：查看正在进行的Snap操作，获取IDsnap changes# 第三步：终止冲突操作（替换ID为上一步查到的冲突ID，如4）snap abort 4

3. 报错“error: snap "core20" has "auto-refresh" change in progress”（自动更新冲突）

# 方法同上，先查看冲突ID，再终止snap changessnap abort 冲突ID

删除完成后，建议验证一下，确保snapd已彻底删除，终端输入以下命令：

# 查看snap命令是否存在（无结果即删除成功）snap list# 查看snapd服务状态（提示“无此服务”即成功）systemctl status snapd

不可否认，snapd的出现，确实解决了Linux系统的一个核心痛点——软件依赖复杂。在没有snapd之前，Linux不同发行版的软件适配是个大难题，Debian系用DEB包、RHEL系用RPM包，安装软件时经常遇到“依赖缺失”的问题，折腾半天都装不上，而snapd的“打包依赖”设计，完美解决了这个痛点，让Linux软件安装变得更简单，这是它的核心价值，值得肯定。

但这并不意味着snapd适合所有场景，尤其是Ubuntu服务器版，它的优点反而会变成“致命缺点”。站在不同角度来看，snapd的争议其实是“需求不匹配”的问题，而非工具本身的好坏。

站在Canonical的角度，推广snapd是合理的商业布局——snapd是Canonical自研的工具，推广它既能提升Ubuntu的用户体验，也能增强自身在Linux领域的话语权，甚至Ubuntu软件商店默认安装的都是Snap格式的软件，哪怕用APT命令安装，有时也会被强制替换成Snap版本。这种布局本身无可厚非，毕竟Canonical作为企业，需要打造自己的生态护城河，而snapd就是关键一环。

但站在服务器运维的角度，snapd的弊端完全无法接受。服务器的核心需求是“稳定、高效、可控”，而snapd的三个特点，刚好戳中了运维的“命门”：一是自动更新无法手动关闭，业务高峰时擅自更新，会占用内存、中断服务，哪怕是1分钟的断服，都可能造成巨大损失；二是资源占用过高，Snap软件的容器化设计，会额外占用30%-200%的磁盘空间，对于内存和磁盘有限的服务器来说，无疑是一种浪费；三是闭源垄断，Snap软件的安装必须依赖Canonical的官方私有服务器，无法搭建私有仓库，相当于被Canonical“卡脖子”，对于注重数据安全的企业来说，这是不可接受的风险。

更值得深思的是，Linux的核心精神是“开源、自由、自主”，用户可以根据自己的需求自由配置系统，而snapd在Ubuntu服务器版中的“强制预装”，恰恰违背了这一精神。很多运维删除的不是snapd本身，而是“被强制”的体验——如果能给用户一个选择，相信很多人不会反感snapd，更不会把它当成“首删目标”。

所以，与其说snapd是“垃圾软件”，不如说它“放错了地方”。对于Ubuntu桌面版用户，尤其是新手，snapd确实能简化软件安装流程；但对于服务器用户，删除snapd，不是否定它的价值，而是选择更适合服务器场景的配置方式，这才是运维的“理性选择”。

四、现实意义：删除snapd，到底能给服务器带来什么好处？

很多运维之所以坚持“安装完就删snapd”，不是跟风，而是删除后带来的好处，实实在在能解决工作中的痛点，甚至能提升工作效率，减少不必要的麻烦，这也是为什么越来越多的运维，会把这一步当成Ubuntu服务器版的“必做操作”。

1. 释放资源，服务器提速明显

snapd后台服务会持续占用内存，哪怕没有安装任何Snap软件，也会消耗几十到几百MB的内存，删除后，这部分内存会被彻底释放，服务器启动速度能提升10%-15%，运行起来也更流畅。同时，清理Snap残留文件后，还能释放500MB-2GB的磁盘空间，对于内存和磁盘有限的轻量服务器来说，无疑是“雪中送炭”。

2. 避免服务中断，提升服务器稳定性

对于企业级服务器来说，“稳定”就是生命线，而snapd的自动更新机制，是服务器稳定运行的“隐形隐患”。删除snapd后，就能彻底避免“高峰时段自动更新导致服务中断”的问题，也能减少软件依赖冲突的概率，让服务器运行更稳定，运维也能少熬夜排查故障，节省大量时间成本。

3. 自主可控，降低安全风险

删除snapd后，服务器的软件安装的管理，会完全通过APT包管理实现，用户可以自主选择软件版本、自主控制更新时间，还能搭建私有软件仓库，不用依赖Canonical的官方服务器，既避免了“被卡脖子”的风险，也能减少恶意软件通过Snap商店入侵服务器的可能，提升服务器的安全性。

4. 简化管理，降低运维成本

对于运维来说，管理的服务器越多，越追求“简洁可控”。snapd的存在，相当于在服务器中多了一套独立的软件管理体系，需要额外学习和维护，增加了运维成本。删除snapd后，软件安装、更新、卸载都能通过APT命令统一管理，流程更简洁，也能减少运维失误的概率，尤其是对于新手运维来说，能快速上手Ubuntu服务器的管理。

当然，也有例外——如果你的服务器确实需要安装某个只能通过Snap格式获取的软件，那么可以暂时保留snapd，用完后再删除。但对于90%以上的服务器场景来说，删除snapd，带来的好处远大于弊端，这也是为什么“安装完就删”会成为运维圈的共识。

五、互动话题：你删除snapd时，踩过哪些坑？

看完这篇文章，相信很多运维朋友都会深有共鸣——谁还没被snapd坑过几次？要么是删除时遇到报错，要么是忘了删除，导致服务器高峰断服，要么是删完后不知道怎么验证，一直担心系统出问题。

其实，删除snapd本身不难，难的是避开那些隐藏的报错，以及明确自己的服务器是否需要保留它。对于Ubuntu服务器版用户来说，“安装完第一时间删除snapd”，早已不是跟风操作，而是经过无数运维验证的“最优解”——既能释放资源、提升稳定性，也能让服务器管理更自主、更省心。

最后，发起一个互动话题，欢迎在评论区留言讨论：

1. 你安装Ubuntu服务器版后，会第一时间删除snapd吗？

2. 删除snapd时，你遇到过哪些报错？是怎么解决的？

3. 你觉得snapd适合服务器场景吗？为什么？

转发这篇文章，给身边正在用Ubuntu服务器的运维朋友，帮他们避开snapd的坑，一起提升服务器运行效率～