目錄
- 1. 什麼是 Snap？
- 2. Snap 的核心設計理念
- 3. Snap 的目錄與文件結構總覽
- 4. /snap 與 ~/snap：系統倉庫 vs 用户保險箱（原文擴展版）
- 5. 版本與通道（channels）機制
- 6. 沙箱與權限（Confinement）模型
- 7. 常用命令速查表
- 8. 舊版本與空間清理
- 9. 與 apt / Flatpak / AppImage 的對比
- 10. 常見問題 FAQ
- 11. 總結速覽表
- 12. 參考與延伸閲讀
1. 什麼是 Snap？
Snap 是 Canonical（Ubuntu 背後的公司）推出的一種跨發行版、原子更新、沙箱化的應用打包與發佈格式。它配套的運行與管理服務稱為 snapd，應用包本身稱為 snap。
一句話概括：開發者把應用及其依賴打成一個只讀 SquashFS 鏡像，用户安裝後由 snapd 掛載運行，並通過嚴格（或放寬）的權限系統控制訪問宿主系統資源。
2. Snap 的核心設計理念
|
目標
|
説明
|
|
一次打包，多發行版運行
|
無需為不同發行版拆分構建（理論上）。
|
|
原子升級 / 可回滾
|
新版本並行掛載，切換指向即可；失敗可 revert。
|
|
沙箱 + 接口授權
|
通過 AppArmor、seccomp、cgroups 限制訪問；使用 interface（接口）來申請權限。
|
|
獨立依賴
|
避免“系統庫升級導致舊應用崩潰”問題。
|
|
自動刷新
|
默認每天定時檢查並更新。
|
3. Snap 的目錄與文件結構總覽
|
路徑
|
作用
|
是否可寫
|
|
|
掛載後的各應用版本目錄（只讀 SquashFS 展開點）
|
否
|
|
|
實際下載的 |
否（root 管理）
|
|
|
snapd 狀態、刷新記錄
|
否
|
|
|
部分應用的持久化/公共數據
|
是
|
|
|
用户級配置、緩存、數據
|
是
|
|
|
systemd unit（自動生成）
|
N/A
|
|
|
緩存與下載中間文件
|
是（可清理）
|
注意：
/snap目錄裏看到的版本號子目錄其實是通過 snapd 把 SquashFS 鏡像 Loop 掛載後呈現出的只讀視圖。
4. /snap 與 ~/snap：系統倉庫 vs 用户保險箱（原文擴展版）
下面內容在原文基礎上重寫為 Markdown，並補充更多背景與示例。
4.1 /snap —— 系統級“程序倉庫”
可類比：Windows 的 C:\Program Files、macOS 的 /Applications。
- 作用：存放應用本體（已掛載的鏡像內容）。
- 只讀：防止篡改，保證版本一致性。
- 多版本並存：例如
spotify/123、spotify/124，舊版本保留以便回滾。 - 所有用户共享：節省重複安裝空間。
4.2 ~/snap —— 用户級“數據/配置保險箱”
可類比：C:\Users\<name>\AppData。
- 存放：個人配置、緩存、數據庫、登錄狀態等。
- 獨立隔離：多用户互不干擾。
- 更新/回滾時通常保留數據，避免丟失。
4.3 為什麼有看似“重複”目錄？
背後是 Bind Mount 與沙箱映射：
- 應用在自身受限視圖裏訪問到的是“虛擬路徑”。
- snapd 通過接口（interface）和 bind mount 暴露你明確允許的目錄或資源。
- 好處：應用“以為”自己在一個自洽環境裏，提高可移植性與安全性。
4.4 快速對比
|
特性
|
|
|
|
角色
|
程序本體（版本掛載點）
|
用户數據與配置
|
|
讀寫
|
只讀
|
可讀寫
|
|
作用範圍
|
系統級（共享）
|
當前用户
|
|
是否可刪
|
不應手動刪（破壞應用）
|
不建議隨意刪（丟數據）
|
|
更新影響
|
版本目錄增加/切換
|
數據通常保留重用
|
結論：兩個目錄互補，缺一不可。不要手工刪除，使用
snap remove --purge <app>進行規範卸載。
5. 版本與通道（channels）機制
每個 Snap 應用有多個“通道” (channel)：
stable（默認，穩定版）candidate（準穩定）beta（測試）edge（最新提交，可能不穩定）
還可帶軌道（track），例如：1.0/stable、2.0/edge，用於並行長期維護不同主版本。
示例：
snap info chromium | grep -A5 channels
sudo snap refresh chromium --channel=beta回滾：
sudo snap revert <app>查看保留的舊版本（保留策略通常是最近 2 個已安裝 revision）：
snap list --all | grep disabled6. 沙箱與權限（Confinement）模型
|
模式
|
説明
|
典型場景
|
|
strict
|
默認；最強沙箱；僅通過接口訪問資源
|
瀏覽器、編輯器
|
|
classic
|
幾乎無限制（類似傳統安裝），需特別審批
|
|
|
devmode
|
開發調試模式，寬鬆且會記錄警告
|
開發者本地測試
|
權限通過 interface 聲明與連接：
snap interfaces <app>
# 手動連接（若自動未成功）
sudo snap connect <app>:removable-media安全底層：AppArmor + seccomp + cgroups + namespaces。
7. 常用命令速查表
|
任務
|
命令
|
|
搜索應用
|
|
|
查看已安裝
|
|
|
安裝
|
|
|
指定通道安裝
|
|
|
更新全部
|
|
|
查看可更新
|
|
|
回滾某應用
|
|
|
卸載
|
|
|
卸載並清理數據
|
|
|
查看佔用空間
|
`du -h /var/lib/snapd/snaps
|
|
設置保留舊版本數
|
|
|
查看接口
|
|
|
手動連接接口
|
|
|
禁止自動刷新（臨時）
|
|
提示：強行長期禁用更新不推薦，會有安全風險。
8. 舊版本與空間清理
8.1 為什麼空間佔用大？
- 每個 revision 是一個完整鏡像（含依賴）。
- 多版本並存 + 緩存 + 經典（classic）應用訪問更多資源。
8.2 清理舊 revision
- 查看：
snap list --all | grep disabled- 刪除（注意謹慎）：
sudo snap remove <name> --revision=<rev>- 或使用 purge：
sudo snap remove --purge <name>8.3 減少自動保留數量
sudo snap set system refresh.retain=28.4 清理緩存
sudo du -sh /var/cache/snapd
sudo rm -f /var/cache/snapd/* # 安全：僅緩存不要手動刪除
/snap、/var/lib/snapd/snaps中的鏡像文件，否則 snapd 狀態會失衡。
9. 與 apt / Flatpak / AppImage 的對比
|
特性
|
Snap
|
apt (deb)
|
Flatpak
|
AppImage
|
|
更新方式
|
原子更新，可回滾
|
依賴系統倉庫，非原子
|
原子（OSTree）
|
手動替換
|
|
沙箱
|
有（strict）
|
無（傳統）
|
有（bubblewrap）
|
基本無
|
|
依賴打包
|
內含大多數依賴
|
共享系統庫
|
runtime + app
|
全部內含
|
|
體積
|
相對偏大
|
最精簡
|
中等
|
中等~大
|
|
啓動速度
|
可能略慢（掛載+沙箱）
|
快
|
略慢（首次部署）
|
快
|
|
跨發行版
|
是
|
否
|
是
|
是
|
|
回滾
|
簡單
|
部分支持（需快照/apt pin）
|
支持
|
手工替換舊文件
|
|
權限管理
|
接口/plug-slot
|
手工（如 AppArmor）
|
Portal 權限
|
無統一機制
|
10. 常見問題 FAQ
Q1: 為什麼第一次啓動很慢？ 需要掛載鏡像 + 生成用户數據 + 建立接口。
Q2: 為何磁盤佔用大？ 含依賴、保留多個 revision、緩存未清理。
Q3: 可以直接刪除 /snap 嗎？ 不行，會破壞運行；使用 sudo snap remove。
Q4: 如何禁用 Snap？ 極端方案是卸載 snapd 並替換為 deb/Flatpak，但 Ubuntu 22.04+ 某些桌面/核心組件依賴 snap（如 snap-store、firefox）。謹慎評估。
Q5: Classic 模式安全嗎？ 它基本放棄沙箱隔離，適用於開發工具；來源可信即可。
11. 總結速覽表
|
關鍵詞
|
要點
|
|
Snap 本質
|
自包含只讀鏡像 + snapd 服務 + 接口權限模型
|
|
兩大目錄
|
|
|
優勢 |
跨平台、一致性、原子更新、可回滾、沙箱化
|
|
劣勢
|
體積偏大、啓動稍慢、佔空間、自動刷新有爭議
|
|
管理建議
|
控制 revision 保留數；定期清理緩存；只從可信渠道安裝
|
|
不要做
|
手動 rm |
