Zephyr RTOS深度解析：轻量实时操作系统设计与GD32移植实战
2026/9/17 1:48:22
1. 先说清楚：snap 到底解决的是谁的痛点
第一次在一台干净的 Ubuntu 上敲sudo snap install code --classic，然后看着进度条跑完、桌面图标自动出现，很多人会以为"这不就是个装软件的捷径"。真拿它做过交付的人不会这么想。snap 是一套带沙箱、带原子更新、带回滚通道的跨发行版应用分发格式，配套一个常驻后台的守护进程snapd，以及一条从源码到商店再到设备的完整工具链。它要解决的核心问题不是"怎么装"，而是"装完之后三年，这个应用还能不能在不折腾用户的前提下安全升级、出问题能不能秒退"。
这篇文章面向三类人：一是在 Ubuntu 或 Ubuntu Core 上做交付、被 apt 依赖冲突折磨过的运维和嵌入式工程师；二是想把内部工具打包成单一产物、发给不同发行版同事的开发者；三是刚接触 Linux、被/snap、/var/snap这些目录搞懵、只想搞懂常用命令的新手。我会把 snap 的机制拆开讲——为什么它要这么设计、每一条命令背后动了什么、打包时哪些参数一步错步步错，最后把我自己踩过的坑整理成可以直接对照的排查表。全文基于常见实践补充实现细节，个别参数在不同版本的 snapd / snapcraft 上可能有差异，以你本机snap --version和snapcraft --version的输出为准。
2. 为什么会有 snap：三个绕不开的老问题
在讲命令之前，值得先花点时间聊清楚"为什么"。因为后面所有的设计细节——只读镜像、通道、接口、回滚——都是从这三个问题里长出来的。搞懂动机，你在遇到报错时才有判断力，而不是照着别人的博客盲试。
2.1 依赖地狱：应用和发行版互相绑架
传统仓库的分发模式是这样的：应用声明"我需要 libfoo >= 1.2"，发行版在发布那一刻把所有包冻结成一套自洽的组合，然后整个系统的库版本就锁死在那个时间点。问题是库会升级、安全补丁会打、新的应用需要新版本。一旦某个签名验证库要从 1.x 升到 3.x，依赖它的几十个包全得重新编译测试，任何一个 ABI 变化都可能拖上几个月。
snap 的做法很直接：不共享系统库。每个 snap 里打包自己的应用文件和它需要的运行时，这个运行时叫 base（比如core22、core24，本质是一个精简的 Ubuntu 根文件系统）。应用在构建时链接的是 base 里的库，运行时也只用 base 里的库，跟宿主机的/usr/lib完全无关。这就把"应用版本"和"系统版本"彻底解耦了——你可以在一台 Ubuntu 20.04 上跑一个用 core24 构建的 snap，因为它自带那一层。
代价也是真实的：每个 snap 都要背一份 base。如果装十个都基于 core22 的 snap，base 只会有一份（按 revision 共享），但如果有的用 core20、有的用 core22，那就是两份完整的根文件系统躺在磁盘上。这是我见过最多的"snap 怎么这么占地方"的来源，后面第 6 节会给具体的处理办法。
2.2 一次打包，多发行版运行：把适配成本从 N 降到 1
做过面向多发行版交付的人对这件事有肌肉记忆。同一个内部工具，你要给 Ubuntu 打 deb、给 Fedora 打 rpm、给 Arch 写 PKGBUILD，还得分别测 Debian 11/12、RHEL 8/9 的库版本差异。每加一个新目标平台，就是一条新的 CI 流水线和一份新的测试矩阵。
snap 改变了这个成本结构：只要目标机器上装了 snapd，同一个.snap文件就能装上去。发布通道里的包只按架构区分（amd64、arm64、armhf 等），不按发行版区分。对内部工具分发来说，这一步省下的时间非常可观——我经手的一个小工具，从"三套打包脚本 + 三套测试"缩减到"一个 snapcraft.yaml + 一条 CI 任务"。
不过别把这句话理解成"snap 万能"。目标机器上得有 snapd；一些极简容器镜像、一些嵌入式环境默认没有；内核和系统级组件（比如驱动、内核模块）不适合用 snap 分发，那些还是要走发行版原生包。
2.3 沙箱与权限：把应用关进笼子里，钥匙交给你
传统 deb 包安装时以 root 身份把文件铺到/usr、/etc，装完这个应用理论上能读写系统任何地方。一次供应链投毒或者一个被攻破的依赖，代价就是整台机器。
snap 默认运行在strict 限制模式下：进程被 AppArmor 规则限定能访问哪些路径、被 seccomp 限定能调哪些系统调用、被 cgroup 限定资源，网络、摄像头、麦克风、家目录这些敏感资源默认都拿不到，必须通过"接口"（interface）显式授权。装完一个 snap 之后snap connections <name>看到的那些:plug和:slot，本质上就是一份权限清单。
这套设计带来的直接后果是：很多"装上了但跑不起来"的问题，原因不是软件坏了，而是权限没连上。知道了这一点，后面排障方向就明确了。
3. 机制拆解：一次snap install到底发生了什么
3.1 从 squashfs 镜像到挂载点
一个.snap文件其实就是一个squashfs 只读压缩镜像，后缀名不同而已（你把它改名成.img用unsquashfs -l也能看内容）。安装时的实际动作大致是：
snapd从商店把镜像下载到/var/lib/snapd/snaps/<name>_<revision>.snap；- 校验签名与校验和；
- 通过 loop 设备把这个镜像挂载到
/snap/<name>/<revision>/（Ubuntu Core 上则是dm-verity校验后挂载，镜像完整性由内核层面保证）； - 在
/snap/bin/下创建命令软链接； - 如果是后台服务型 snap，生成 systemd unit。
理解"只读"这两个字很关键。snap 的安装目录你改不了，/snap/<name>/current/只是一个指向当前 revision 的符号链接。所有可写的数据都必须落在别处：用户数据在~/snap/<name>/<revision>/，系统数据在/var/snap/<name>/<revision>/。这是我在给别人做 snap 打包支持时被问得最多的一点——"我的程序要写配置文件到安装目录"，答案是不行，必须改路径。
3.2 通道（channel）：一条轨道上的四个档位
snap 的版本管理不走"版本号"，走通道。格式是[track/]<risk>/<branch>，最常见的四种风险级别：
| 通道 | 定位 | 适合谁 |
|---|---|---|
stable | 经过完整测试的正式版，默认安装目标 | 生产环境、普通用户 |
candidate | 候选发布，等价于 RC | 发布前验证，愿意报 bug 的人 |
beta | 功能基本可用但未必稳定 | 尝鲜用户、功能验证 |
edge | 每天自动构建，随时可能挂 | 开发者、CI 冒烟测试 |
track 用来分大版本线，比如2.x/stable、3.x/stable，适合同时维护两条 LTS 分支的项目。branch 是临时分支通道，比如某个紧急修复的hotfix-123/stable，用于小范围灰度。
通道机制真正的价值在回滚。snap revert <name>会把符号链接指回上一个 revision，一两秒完成，不用重新下载也不用重装。这个能力在"升级后线上服务起不来"的场景下能救命。注意snap revert只能退一个 revision，而且退回去之后 snapd 会在下一个自动刷新窗口再把你升上去——除非你用snap refresh --hold冻住。
3.3 接口机制：plug 与 slot 的语言
接口是 snap 沙箱的开关体系。理解一句话就够：应用侧声明 plug（我需要什么），系统或其他 snap 提供 slot（我能给什么），snapd 在中间做匹配和授权。
常见的自动连接（安装时自动完成）：network、network-bind、home（部分受限）、desktop、x11、wayland、opengl、audio-playback。常见的需要手动连接：removable-media、camera、system-observe、snapd-control、docker。
几个实操细节：
snap connections <name>看某个 snap 的连接状态；snap interface <接口名>看这个接口的定义、哪些 snap 在用它；sudo snap connect <snap>:<plug> <slot>手动连；sudo snap disconnect ...断开。
有个反直觉的点：自动连接不等于已连接。有些接口因为安全评级较高，需要你手动connect，而snap install不会报错也不会提醒，只在snap connections里显示为未连接。新手最容易在这里卡半天。
3.4 目录布局：文件都去哪了
| 路径 | 用途 | 可写 |
|---|---|---|
/snap/<name>/<rev>/ | 挂载后的只读应用根 | 否 |
/snap/<name>/current | 指向当前 revision 的软链 | 否 |
/snap/bin/ | 命令软链，通常在 PATH 里 | 否 |
/var/lib/snapd/snaps/ | 下载下来的.snap镜像本体 | root |
/var/lib/snapd/seed/ | 系统预装/种子 snap | root |
/var/lib/snapd/snaps/+.../snapd | 守护进程自身 | root |
/var/snap/<name>/<rev>/ | 系统级可写数据、服务状态 | 是 |
/var/snap/<name>/common/ | 跨 revision 共享的系统数据 | 是 |
~/snap/<name>/<rev>/ | 用户级数据 | 是 |
~/snap/<name>/common/ | 跨 revision 共享的用户数据 | 是 |
common目录的设计值得单独说一句。因为 revision 会随着更新变化，把数据写在<rev>目录里每次更新都会"丢"，所以需要跨版本保留的东西（数据库、模型文件、用户配置）必须放common。打包时用$SNAP_USER_COMMON、$SNAP_COMMON这两个环境变量来定位，别硬编码路径。
4. 上手实操：装好 snapd 并跑通第一个 snap
4.1 在主流发行版上安装 snapd
Ubuntu 16.04 之后默认自带，其他发行版要手装。
# Debian 12 / Ubuntu sudo apt update sudo apt install -y snapd # Fedora sudo dnf install -y snapd sudo ln -s /var/lib/snapd/snap /snap # Arch / Manjaro sudo pacman -S --needed snapd sudo systemctl enable --now snapd.socket # openSUSE sudo zypper addrepo --refresh https://download.opensuse.org/repositories/system:/snappy/openSUSE_Leap_15.5 snappy sudo zypper --gpg-auto-import-keys refresh sudo zypper dup --from snappy sudo zypper install snapd装完检查一下：
snap version # 看 snapd 与 snap 客户端版本 systemctl status snapd # 守护进程是否在跑 echo $PATH | tr ':' '\n' | grep snap # /snap/bin 是否在 PATH 中注意：Fedora 上必须建
/snap这个软链，否则挂载点不存在，所有 snap 都会启动失败。这是 Fedora 用户第一号翻车点，官方文档里写了但很容易被跳过。
如果你的 shell 提示找不到snap命令但systemctl显示服务在跑，通常是/snap/bin没进 PATH，重新登录一次或者手动export PATH=$PATH:/snap/bin。
4.2 日常命令速查
# 搜索与查看信息 snap find "keyword" # 商店搜索 snap info <name> # 版本、通道、体积、连接点 # 安装与卸载 sudo snap install <name> sudo snap install <name> --channel=beta sudo snap install <name> --classic # 需要审核通过的 classic 权限 sudo snap remove <name> sudo snap remove <name> --purge # 连数据一起删 # 列表与更新 snap list snap list --all # 含已禁用的旧 revision snap refresh --list # 只列出待更新，不执行 sudo snap refresh sudo snap refresh <name>snap list --all里会看到某些 revision 显示disabled，那是被保留的旧版本，用于回滚。它们占磁盘，通过snap remove <name> --revision=<n>可以单独清掉（注意别删当前正在用的那个）。
4.3 通道切换、回滚与冻结更新
# 切到 beta 通道 sudo snap refresh <name> --channel=beta # 回滚到上一个 revision sudo snap revert <name> # 冻结自动更新 24 小时（做演示、跑长任务时很有用） sudo snap refresh --hold=24h sudo snap refresh --hold=72h # 解除 sudo snap refresh --unhold # 看定时刷新计划 snap refresh --timesnap refresh --time输出里会告诉你下次刷新窗口和上次刷新时间。默认一天检查四次，分布在随机时间点。生产服务器上我一般会显式设置窗口，避免它在业务高峰做挂载切换：
sudo snap set system refresh.timer=mon,thu,4:00-6:00顺手把旧 revision 保留数从 3 改成 2，可以在磁盘紧张时省出可观空间：
sudo snap set system refresh.retain=2 # 取值范围 2-20提示：
refresh.retain的值不能设成 1。设 1 会导致回滚能力失效，snapd 会直接拒绝。
4.4 服务型 snap 与配置项
很多系统组件（比如 k8s 相关的一堆组件、监控 agent）是以 snap 形式提供的后台服务。
snap services <name> # 列服务及状态 sudo snap start <name>.<service> sudo snap stop --disable <name>.<service> sudo snap restart <name>.<service>配置项走snap set/snap get，具体支持哪些 key 由打包者在 snapcraft.yaml 里声明：
snap get <name> # 看当前配置 snap get <name> -d # 输出 JSON sudo snap set <name> key=value这套配置机制的好处是配置本身也被 snapd 管着，会被记录在snap changes的历史里，出问题能追溯是谁在什么时候改了什么。这一点比直接改/etc下的文件要可靠。
5. 打包自己的 snap：从 snapcraft.yaml 说起
5.1 最小可用结构
snapcraft.yaml是唯一的入口文件，放在项目根目录。一个能跑的最小例子：
name: mytool base: core22 version: '1.2.0' summary: 一句话说明，不超过 79 字符 description: | 多行描述。写清楚这个工具做什么、 有哪些限制、首次使用需要注意什么。 grade: stable confinement: strict architectures: - build-on: amd64 - build-on: arm64 apps: mytool: command: bin/mytool plugs: - network - home parts: mytool: plugin: dump source: ./dist organize: mytool: bin/mytool逐字段说一下容易踩的地方：
name：全局唯一，只能小写字母、数字、连字符，且不能以连字符开头或结尾。一旦发布就改不了，改名等于重新上架。base：决定运行时的 Ubuntu 版本，也决定构建环境。core22 对应 22.04 的根文件系统。新项目优先 core22 或 core24，core20 已经偏老。version：纯字符串，别写数字，否则1.10会被当成1.1。summary：79 字符上限，超了直接构建失败，这个限制很硬。confinement：strict是默认也是最推荐的；classic需要商店人工审核，只有确实无法沙箱化的工具（IDE、需要访问宿主工具链的编译器）才用；devmode是开发期的"只记录不拦截"模式，绝对不能发布到 stable。
5.2 构建环境：别用 destructive-mode 图快
snapcraft默认会在虚拟机或 LXD 容器里构建，这保证了构建环境的纯净和可复现。第一次跑会拉镜像，慢是正常的。
# 默认后端，自动选择 snapcraft pack # 显式指定用 LXD（推荐在 Linux 上用，比 Multipass 快很多） snapcraft pack --use-lxd # 指定只构建某架构 snapcraft pack --build-for=arm64注意：
--destructive-mode会在当前机器上直接构建，速度快但会往宿主机里装一堆构建依赖。我曾经在开发机上用它构建一个 Python 项目，结果把系统的 Python 包环境污染了，后面排查了半天。除非在一次性容器里，否则建议老老实实用 LXD。
有个很实用的调试开关：
snapcraft try它会把构建结果展开到当前目录的prime/里，然后你可以用snap try prime/把它"安装"成开发模式 snap。改代码后重新构建，不用重新安装就能生效（因为是直接指向目录而不是挂载镜像）。做迭代开发时这个流程比pack+install --dangerous快得多。
5.3 part 与插件：把构建逻辑组织好
part 是构建单元，每个 part 描述"从哪拿源码、怎么编译、装到哪"。常用的插件：
| 插件 | 用途 | 常见坑 |
|---|---|---|
dump | 直接拷贝已经编译好的产物 | 注意organize里的路径映射 |
nil | 不构建，只做放置 | 适合打包纯脚本 |
cmake | CMake 项目 | 需要显式声明build-packages |
autotools | configure/make 项目 | configflags传参容易出错 |
python | Python 应用 | 必须指定python-packages，不指定就是空环境 |
nodejs | Node 应用 | 锁文件必须提交，否则构建不可复现 |
go | Go 项目 | 模块缓存路径需要配置 |
rust | Rust 项目 | 编译慢，建议加build-attributes: [no-system-libraries]谨慎使用 |
make | 自定义 Makefile | 最灵活，也最需要自己处理依赖 |
多 part 时的依赖顺序用after:显式声明，别指望 snapcraft 猜。多个 part 都会往$SNAPCRAFT_PART_INSTALL里放东西，最后统一合并到prime/，路径冲突时后处理的会覆盖前面，这个顺序问题在打包静态资源和配置模板时特别容易出乱子。
5.4 本地安装调试与发布
# 本地装一个未签名的 snap（开发用） sudo snap install --dangerous ./mytool_1.2.0_amd64.snap # 开发模式安装，沙箱只告警不拦截 sudo snap install --devmode --dangerous ./mytool_1.2.0_amd64.snap # 静态检查（提交前必跑） snapcraft lint ./mytool_1.2.0_amd64.snap # 登录并上传 snapcraft login snapcraft upload --release=stable ./mytool_1.2.0_amd64.snap--dangerous这个参数名字很吓人，它的含义是"跳过签名校验"，仅限本地开发。千万不要在自动化脚本里对从外部拿到的.snap用它。
CI 里发布通常用导出的凭据，避免明文账号密码：
snapcraft export-login --snaps=mytool --channels=stable snapcraft-login.txt # 文件里是短期凭据，在 CI 里配合环境变量注入6. 排障实录：那些让人抓头发的报错
6.1 三把排障的"万能钥匙"
这三个命令基本能覆盖九成运行时问题，建议记牢：
# 1. 以相同沙箱环境开一个 shell，手动跑命令看真实报错 sudo snap run --shell mytool # 进入后手动执行 $SNAP/bin/mytool，报错信息完整得多 # 2. 看系统日志里 AppArmor / seccomp 的拒绝记录 sudo journalctl -f -u snap.mytool.* # 服务型 snap sudo dmesg | tail -50 # AppArmor DENIED 会在这里 # 3. 看连接状态 snap connections mytoolsnap run --shell是我最常用的一个。直接启动应用时被沙箱拦下来，日志往往只有一句干巴巴的 "Permission denied"，进 shell 里手动跑同一个二进制，通常能看到"无法写入 /home/xxx/.config/yyy"这类明确的路径信息，顺着路径查接口就快了。
6.2 典型问题速查表
| 现象 | 大概率原因 | 处理方式 |
|---|---|---|
| 装完命令找不到 | /snap/bin不在 PATH | 重新登录或改/etc/environment |
| 启动即退出，无输出 | 缺接口授权 | snap connections查未连接项，手动connect |
| 无法读写 U 盘 | 缺removable-media | snap connect <name>:removable-media |
| 写不了家目录下的隐藏目录 | home接口默认不含隐藏文件 | 把配置放$SNAP_USER_DATA或申请personal-files |
| 服务型 snap 反复重启 | 前台运行问题 / 路径错 | journalctl -u snap.<name>.*看退出码 |
| 升级后服务起不来 | 新版本引入问题 | snap revert <name>秒退，再排查 |
| 磁盘莫名被吃掉几 GB | 旧 revision 累积 | snap list --all+ 调小refresh.retain |
--classic安装被拒 | 该 snap 未获 classic 权限 | 换 strict 版本或申请权限 |
| 字体 / 主题和系统不一致 | 沙箱无法访问宿主主题资源 | 装gtk-common-themes，或接受默认外观 |
| 构建时 summary 报错 | 超过 79 字符 | 精简描述 |
6.3 两个真实踩坑记录
坑一：数据写在<rev>目录里。早期我做一个采集工具，图省事把 SQLite 数据库放在$SNAP_DATA下。第一次自动更新之后用户反馈"数据全没了"——因为$SNAP_DATA指向的是/var/snap/tool/<rev>/，revision 一变就是新目录。正确做法是放$SNAP_COMMON。改完之后一切正常，但那次事故让我在后续所有项目的第一条编码规范里都写了这一句：跨版本持久化的东西一律走COMMON。
坑二：classic 的依赖是宿主的，别当救心丸。有个工具因为要调用宿主机上的编译器，我给它申请了classic。结果是它在开发机上跑得好好的，到了另一台库版本不同的机器上就报符号找不到。因为 classic 模式下它链接的是宿主机库，跨发行版一致性这个 snap 最核心的优势就没了。最后的方案是老老实实做 strict 打包，把需要的工具链塞进 part 里。
7. 和其他包管理器摆在一起看，各自站什么位置
7.1 与 apt / dnf 的分工
这两层的定位其实不冲突，反而经常配合。
| 维度 | apt / dnf | snap |
|---|---|---|
| 打包对象 | 系统组件、库、内核相关 | 应用、服务、工具链 |
| 依赖处理 | 全局共享，版本冲突风险高 | 自带运行时，互不影响 |
| 更新粒度 | 整系统一起升 | 单应用独立升 |
| 回滚 | 麻烦，要降级多个包 | snap revert一条命令 |
| 沙箱 | 基本没有 | 默认 AppArmor + seccomp |
| 体积 | 小（共享库） | 大（自带 base） |
| 适合场景 | 基础系统、驱动、库 | 上层应用、跨发行版交付 |
我自己的习惯是：系统层用 apt，业务应用用 snap，两者边界清晰。遇到snap不合适的场景（内核模块、需要深度集成系统服务的组件）就老老实实回 apt，别硬套。
7.2 与 flatpak、AppImage、容器方案的差异
| 方案 | 运行时共享 | 沙箱 | 更新机制 | 最适合 |
|---|---|---|---|---|
| snap | base 快照，多个应用共享同一 base | 有，接口授权 | 后台自动 + 通道回滚 | 桌面应用 + 服务 + IoT |
| flatpak | runtime，粒度较细 | 有，portal 机制 | 依赖宿主工具 | 纯桌面 GUI 应用 |
| AppImage | 完整自带 | 无 | 手动替换文件 | 单文件分发、免安装 |
| 容器镜像 | 完全自带 | 强隔离 | 由容器编排管理 | 服务端、微服务 |
简单说：AppImage 是"一个文件拷过去就能跑"，最省事但没沙箱没更新；flatpak 在桌面 GUI 场景生态很好；容器解决的是另一个层面的问题，服务端部署的原子性和编排能力比 snap 强得多。判断标准是你要交付的是"一个应用"还是"一个系统"：前者 snap 很顺手，后者还是容器或系统镜像。
7.3 横向看，现代包管理器都在解决同一类问题
把视野拉开一点会发现，近些年主流的包管理工具——不管是 Python 的uv、JS 的 pnpm、Rust 的 cargo——设计思路和 snap 惊人地相似：
- 锁定与可复现：
uv.lock、package-lock.json对应 snap 的 revision 和通道，都是为了让"昨天能跑的今天还能跑"； - 隔离：
uv的虚拟环境对应 snap 的 base，都是"自带一份依赖，别污染全局"； - 原子安装与回滚：
uv的缓存硬链接、cargo 的Cargo.lock加 registry，都是为了让动作可撤销； - 内容寻址：snap 的 revision 号、
uv的哈希索引，本质是同一个思路。
搞懂一层的设计动机，换到另一层几乎能立刻上手。这也是我为什么建议刚接触 Linux 包管理的朋友，不要只背命令，而是挑一个把机制吃透——剩下的都是同一套思想的变体。
8. 嵌入式与设备端：snap 的另一条主战场
8.1 只读根文件系统 + 原子更新意味着什么
在嵌入式设备上，最怕的场景是"升级过程中断电，设备变砖"。传统做法是双分区 A/B 切换，逻辑复杂、空间占用大。
Ubuntu Core 的思路是：根文件系统只读，系统本身和每个应用都是 snap。升级某个应用时，snapd 先把新 revision 完整下载并校验完，然后原子地切换软链指向。切换动作本身是瞬时的，断电最多导致"要么旧版要么新版"，不会出现半新半旧的状态。这就是所谓的原子性，也是为什么很多做设备交付的团队会选这套方案。
8.2 从开发机到设备端的流程
大致链路是：开发机上用 snapcraft 构建应用 snap → 构建一个自定义的"模型断言"（model assertion）描述这台设备预装哪些 snap → 产出最终系统镜像 → 刷入设备 → 设备从商店拉取后续更新。
模型断言本质是一份签名过的 JSON，声明设备型号、架构、预装的 snap 列表和它们的通道。这份文件一旦签名，任何修改都需要重新签名，防止设备端被随意篡改预装内容。
对应用开发者来说，设备端要关心的事情比桌面多几条：
- 架构：嵌入式板子多是 arm64 或 armhf，构建时要用
--build-for指定，或者用多架构构建流； - 资源：内存和磁盘都紧张，base 的选择要慎重，core22 比 core20 大一圈；
- 串口与 GPIO：要访问硬件外设，接口声明必须写清楚，否则沙箱直接拦；
- 启动时间：服务型 snap 的启动顺序用
apps.<name>.after和before控制，别指望默认顺序。
8.3 团队协作里最容易出问题的两点
第一，通道规划没想清楚就开始发版。我见过一个团队把 dev、test、prod 三套环境全压在stable上，靠版本号区分。结果是测试环境要回滚就必须动生产环境的包。正确做法是给不同环境用不同的 track 或 channel，比如stable给生产、candidate给预发、edge给联调环境，物理隔离比流程约束可靠得多。
第二，把 secrets 打进 snap 里。snap 是只读镜像，任何人unsquashfs一下就能看到里面所有文件。凭据、密钥、设备证书一律不能放进去，必须通过设备端配置文件、snap set或者外部服务下发。这条听起来像废话，但我确实在别人的包里见过硬编码的访问令牌。
9. 我个人在实际操作中攒下的几条经验
第一，刚上手别急着打包，先玩透snap connections和snap run --shell。这两个命令能解决你 80% 的困惑。打包本身是体力活，排障才是技术活。
第二，磁盘紧张时先看snap list --all的 disabled 项，再考虑动 base。很多人第一反应是"snap 太占地方了要卸载"，其实清掉几个旧 revision 往往就能回收好几 GB，而且零风险。
第三，给内部工具做 snap 时，把confinement从 strict 开始写。一开始就上 classic 会省事，但后面想收紧到 strict 基本等于重做一遍接口设计，早做早轻松。
第四，自动更新一定要在服务端显式设置时间窗口。refresh.timer设成业务低峰，可以避免"凌晨三点服务重启"这种事变成早上的事故报告。桌面机器倒无所谓，服务端机器上这条几乎是必须的。
第五，snapcraft lint请当成提交前的必跑项。它能提前抓出很多商店审核会拒绝的问题，比如无效的桌面文件、缺失的图标、不规范的 name，返工一次的时间远大于跑一次 lint。
第六，跨版本持久化数据，路径一律写$SNAP_COMMON或$SNAP_USER_COMMON。这是我从一次真实的数据丢失里换来的教训，写进团队编码规范之后就没再犯过。
这个方向后续还能往下挖的地方不少：比如用snap save/snap restore做系统状态的快照与恢复，比如自定义接口（content interface）实现两个 snap 之间的数据共享，再比如把构建流水线接进 CI 做多架构并行出包。这些等我把手上这套设备端交付跑顺了，再单独写一篇。