Ubuntu20下加速snap安装的3种实用技巧

1. 为什么你的Snap安装慢如蜗牛？先搞清楚原因

如果你在Ubuntu 20.04上用过snap install，大概率经历过那种看着进度条半天不动，甚至直接报错connection timed out的绝望。这种感觉我太懂了，几年前我第一次用snap装VSCode，等了快半小时，最后还失败了，当时差点以为网络出了问题。后来折腾多了才明白，这锅还真不能全让自家网速背。

简单来说，snap是Canonical（Ubuntu背后的公司）力推的一种新的软件打包格式。它把软件和它所有的依赖库、运行时环境都打包成一个独立的“容器”，好处是软件在任何Linux发行版上都能跑，而且更新、回滚特别方便。但问题也出在这里——这些打包好的.snap文件，默认都是从国外的Snap Store服务器下载的。

对于国内用户，尤其是网络环境不那么理想的情况下，这个跨国下载的过程就变成了速度的瓶颈。你可以把它想象成海淘：东西是好东西，但清关、运输的等待时间实在太长。更关键的是，snap在设计上没有像apt那样内置成熟的镜像源替换机制。apt你可以轻松换成清华、阿里、中科大的源，速度瞬间起飞。但snap的官方文档里，对镜像的支持一直比较模糊，社区里也没有一个像apt那样被广泛认可的国内镜像站。

所以，慢，是常态。但别急着放弃，snap生态里确实有一些好用且独有的软件，比如一些最新的开发工具、跨平台应用。接下来我要分享的三种方法，都是我这些年实战踩坑后总结出来的，能实实在在地把安装速度从“步行”提升到“高铁”。咱们先从最直接、但需要一点前置条件的方法说起。

2. 方法一：为Snap配置网络代理（最彻底的提速方案）

这个方法的核心思路是“借道”，让snap的流量通过一个更快的网络路径去访问国外的服务器。它适合那些本身已经具备良好国际网络访问条件的环境，比如一些科研机构、企业的网络，或者你自己搭建了代理服务的情况。

重要提示：这里讨论的“代理”是广义的网络代理技术，用于优化网络请求路径。你必须确保你使用的任何网络工具和服务完全遵守所在地的法律法规，仅用于学习、开发等合法合规的用途。

2.1 为Snapd系统服务设置代理

Snap的后台服务叫snapd。它是以系统服务（systemd service）的形式运行的。所以，要让它走代理，我们需要修改它的服务启动环境。

首先，创建一个专用的配置文件目录和文件：

sudo mkdir -p /etc/systemd/system/snapd.service.d sudo nano /etc/systemd/system/snapd.service.d/snap-proxy.conf

在这个新文件里，你需要根据你实际使用的代理类型和地址进行配置。下面是一个最常见的HTTP/HTTPS代理的配置示例：

[Service] Environment="http_proxy=http://你的代理服务器地址:端口" Environment="https_proxy=http://你的代理服务器地址:端口" Environment="no_proxy=localhost,127.0.0.1,.local"

配置说明：

• 将你的代理服务器地址:端口替换为你实际可用的代理地址，例如192.168.1.100:8080或一个可解析的域名。
• no_proxy设置了不走代理的例外地址，本地通信不需要绕远路。

保存并退出编辑器（在nano中是Ctrl+X，然后按Y确认，再按回车）。

2.2 让配置生效并测试

修改了systemd的配置后，必须重载服务并重启snapd：

# 重新加载systemd配置，使其识别新的服务文件 sudo systemctl daemon-reload # 重启snapd服务，让代理设置生效 sudo systemctl restart snapd

现在，你可以测试一下速度了。找一个之前安装很慢的snap包试试，比如安装hello-world这个测试包：

time sudo snap install hello-world

留意命令执行的时间。如果配置正确，你应该能感觉到下载速度有明显提升。time命令会告诉你整个安装过程实际花了多久，可以和之前不配置代理的情况做个对比。

2.3 这个方法适合谁？有什么坑？

适用场景：

• 你的网络环境本身可以通过配置全局或应用代理来优化国际访问。
• 你需要在多台机器上统一加速snap，通过配置代理可以批量解决。
• 你对命令行和系统服务配置比较熟悉。

需要注意的坑：

1. 服务重启：每次修改代理配置，都必须执行daemon-reload和restart snapd，否则不生效。
2. 代理稳定性：你的代理服务器本身必须稳定且速度够快，否则可能适得其反。
3. 认证问题：如果你的代理需要用户名密码认证，配置会稍微复杂一点，需要在地址中包含认证信息，例如http://用户名:密码@代理地址:端口。但要注意，这样明文存储密码有安全风险，更安全的方式是使用支持认证文件或环境变量的代理工具。
4. 并非万能：这个方法依赖于一个稳定可靠的代理出口。如果这个出口本身带宽不足或不稳定，加速效果就会打折扣。

3. 方法二：离线安装法（无需网络等待，一劳永逸）

当你网络条件实在不好，或者需要在多台无法联网的机器（比如内网开发机）上部署同一个snap软件时，离线安装就是你的“杀手锏”。它的原理很简单：在一台能联网的机器上先把软件包和它的“身份证”（断言文件）下载下来，然后拷贝到目标机器上安装。

3.1 详细步骤拆解：以安装Pycharm为例

假设我们想在机器B上安装Pycharm，但机器B网速很慢。我们可以在网速快的机器A上操作。

第一步：在机器A上使用snap download下载

在机器A上打开终端，执行：

sudo snap download pycharm-community

这个命令会做两件事：

1. 下载一个.snap文件，这就是软件的完整包，体积较大。
2. 下载一个.assert文件，这是软件的断言文件，相当于软件的“数字签名”和元数据证明，确保软件来源可信且完整。

命令执行后的输出会类似这样：

Fetching snap "pycharm-community" Fetching assertions for "pycharm-community" Install the snap with: snap ack pycharm-community_222.assert snap install pycharm-community_222.snap

它会很贴心地告诉你接下来在目标机器上该怎么安装。

第二步：将文件传输到目标机器B

你可以用U盘、内网共享、scp命令等任何方式，把下载好的pycharm-community_222.snap和pycharm-community_222.assert这两个文件拷贝到目标机器B的某个目录下，比如~/Downloads/。

第三步：在目标机器B上执行离线安装

在机器B上打开终端，进入存放文件的目录，然后严格按照提示的顺序执行：

# 首先，使用 snap ack 命令“确认”或“注册”这个断言文件。 # 这个操作告诉系统：“我信任这个软件包的身份信息。” sudo snap ack ./pycharm-community_222.assert # 然后，安装本地的 .snap 文件。 # --classic 参数对于像Pycharm、VSCode这类需要深度访问系统资源的IDE通常是必需的。 sudo snap install ./pycharm-community_222.snap --classic

如果一切顺利，你会看到pycharm-community 2020.3 from jetbrains✓ installed这样的成功提示。之后你就可以在应用程序菜单里找到它了。

3.2 进阶技巧：批量部署与版本管理

离线安装的魅力不止于此。想象一下，你是一个团队的技术负责人，需要为所有开发人员的电脑统一安装某个特定版本的IDE（比如VSCode 1.80），以确保开发环境一致。

你可以这样做：

1. 在一台机器上使用snap download code --channel=1.80/stable下载指定版本的VSCode。
2. 将这个版本的.snap和.assert文件存放在内网文件服务器或共享目录中。
3. 编写一个简单的安装脚本，分发给团队成员，脚本内容就是上面的ack和install命令。
4. 大家运行脚本，几分钟内就能完成统一部署，完全不受外网速度和软件版本更新的影响。

这不仅能保证环境统一，还能避免因网络问题导致的安装失败，极大提升了效率。

3.3 离线安装的优缺点分析

优点：

• 速度极快：安装过程完全在本地进行，速度取决于你的硬盘读写，秒级完成。
• 环境隔离：非常适合内网、无外网或网络受限的生产环境。
• 版本固化：可以精确控制安装的软件版本，避免自动更新带来的意外问题。
• 可重复性强：一次下载，无限次安装，特别适合批量部署。

缺点：

• 需要手动下载：需要有一台能联网的“跳板机”先行下载。
• 无法自动更新：离线安装的软件不会自动从Snap Store获取更新。你需要手动下载新版本重复此过程。
• 管理成本：当需要管理的软件和版本较多时，需要自己做好文件版本的归档和管理。

4. 方法三：寻找并配置Snap镜像源（最像APT的体验）

这是很多用户最期待的方法——像换apt源一样，给snap也换上一个国内的镜像站。理想很丰满，但现实是，Snap官方并未像APT那样正式支持并列出可选的镜像源列表。社区里有一些尝试和第三方镜像，但普遍存在维护不及时、软件不全或已停止服务的问题。

因此，这个方法更像是一个“探索性”的解决方案，我把它分为两个层面：官方实验性支持和社区探索。

4.1 了解Snap的“商店代理”功能

Snapd其实有一个实验性的“商店代理”（store proxy）功能。它的设计初衷是让企业或组织在内网搭建一个Snap软件的缓存服务器，内网的所有机器都从这个缓存服务器下载，从而节省外网带宽并加速安装。

配置它需要搭建一个snap-store-proxy服务，这个过程相对复杂，涉及到初始化代理、生成SSL证书、将客户端机器注册到代理等步骤。对于个人用户或小团队来说，维护这样一个服务的成本可能超过了其带来的便利。不过，如果你是在一个大型机构，有专门的运维团队，这倒是一个值得考虑的方案，可以一劳永逸地解决整个机构内snap的安装速度问题。

4.2 谨慎尝试社区镜像（风险自担）

网络上偶尔能搜索到一些爱好者搭建的snap镜像地址。使用这些镜像通常需要修改snap的配置，指定一个不同的商店URL。

重要警告：使用非官方镜像存在安全风险。你无法保证镜像站提供的软件包没有被篡改。因此，如果你决定尝试，请务必仅用于测试环境，并且清楚潜在的风险。

如果非要尝试，理论上可以通过以下方式修改（再次强调，请自行评估风险，以下仅为技术路径演示）：

# 首先，查看当前的商店设置 sudo snap get system proxy.store # 如果需要设置（假设你找到了一个可信的镜像站URL） sudo snap set system proxy.store=https://mirror.example.com/

设置完成后，同样需要重启snapd服务：sudo systemctl restart snapd。

4.3 为什么Snap镜像源这么少？

这背后有几个原因：

1. 技术机制不同：Snap包是只读的压缩镜像文件，更新时采用增量更新（delta update）机制，这比APT的deb包管理要复杂，搭建一个能正确处理所有更新和断点续传的镜像服务门槛较高。
2. 带宽和存储成本高：Snap包通常比deb包大很多（因为它包含所有依赖），维护一个全量且及时的镜像需要巨大的存储空间和网络带宽。
3. 官方推动力：Canonical更倾向于推广其官方的Snap Store，对于第三方镜像的生态建设支持力度不如APT源那样大。

所以，目前来看，对于大多数个人用户，方法一（代理）和方法二（离线安装）是更可靠、更实用的选择。方法三可以作为未来官方功能完善后的一个备选方向，或者供有能力和条件的企业用户深入研究。

5. 综合策略与日常使用建议

讲完了三种核心方法，我们再来聊聊怎么把它们灵活运用到实际工作中，以及一些让snap用起来更顺手的小技巧。

5.1 如何根据场景选择最佳方案？

我把这几种方法的选择逻辑总结成下面这个表格，你可以对号入座：

5.2 提升Snap使用体验的必备命令

除了安装，管理好snap软件也很重要。这几个命令我几乎天天用：

• 查看已安装的snap软件：snap list。一目了然，比在软件中心里找快多了。
• 更新所有snap软件：sudo snap refresh。这相当于sudo apt upgrade，一键更新所有通过snap安装的软件到最新稳定版。
• 更新特定软件：sudo snap refresh 软件名。比如只更新VSCode：sudo snap refresh code。
• 切换到其他更新通道：sudo snap switch --channel=channel-name 软件名。Snap有stable（稳定）、candidate（候选）、beta（测试）和edge（前沿）四个通道。如果你想尝鲜最新（可能不稳定）的特性，可以切换到beta或edge通道。
• 彻底删除一个snap软件：sudo snap remove --purge 软件名。加上--purge会同时删除该软件的用户数据和配置，非常干净。

5.3 关于“经典模式”（classic confinement）的说明

你在安装一些软件（如Pycharm、VSCode）时，会看到我加了--classic参数。这是因为snap默认采用“严格限制”（strict confinement）模式，软件在一个沙箱中运行，不能随意访问你的主目录或系统其他部分，很安全。

但有些软件（特别是功能强大的开发工具）需要更广泛的系统权限才能正常工作。--classic模式就解除了这个沙箱限制，让它像传统安装的软件一样拥有更多自由。安装时，如果终端提示你需要--classic，或者软件官方文档有说明，那就加上它。当然，你也要明白，这相当于你信任了这个软件的发布者。

6. 写在最后：我的实战心得

在Ubuntu下和snap“斗智斗勇”这么多年，我的心态已经从最初的排斥变成了现在的“灵活利用”。它确实有缺点，安装慢、包体积大，但它的优点也同样突出：版本统一、隔离性好、回滚方便。

对于速度问题，我现在的工作流是这样的：在我的主力开发机上，我配置了稳定的网络环境（相当于方法一），所以日常snap install很顺畅。当我需要为团队的新电脑或者服务器部署环境时，离线安装包（方法二）是我的首选，我甚至在自己的NAS上建了一个文件夹，专门存放常用软件的各个稳定版本的snap包，就像一个小型的内网软件仓库。

至于镜像源，我仍然在关注社区的动态，但目前不会将希望寄托于此。技术的演进需要时间，也许未来某天，Snap官方会推出更友好的镜像支持方案。

说到底，在Linux世界里解决问题，从来就没有唯一的“银弹”。核心思路是理解工具的原理，然后根据手头的资源和具体的场景，选择最合适的那把“螺丝刀”。希望我分享的这三种方法，能帮你把snap这个工具用得更加得心应手，至少别再被漫长的安装等待消磨了热情。如果遇到其他问题，多查查官方文档，或者看看社区的讨论，很多时候答案就在那里。