Podman 与 Rancher Desktop 选型迁移：比较运行时合同，不比较命令外观
podman run、nerdctl run 和 docker run 长得相似，最多只能降低第一天的记忆成本。团队迁移真正改变的是运行时进程放在哪里、谁拥有状态、哪套 API 可用、镜像和卷存在哪里，以及故障时由谁恢复。没有这些证据，命令替换越顺，后续误判越隐蔽。
Podman 的核心选择是 Linux 上的 daemonless/rootless 用户边界，以及非 Linux 上的 Podman Machine。Rancher Desktop 的核心选择是受管 VM 中的 containerd/nerdctl 或 Moby/Docker API，并可附加本地 Kubernetes。两者都不是 Docker Desktop 的无损皮肤。
先用项目事实筛掉不合适的候选
| 项目事实 | Podman 的含义 | Rancher Desktop 的含义 |
|---|---|---|
| 主要开发机是 Linux，希望容器状态按用户隔离 | Rootless 是一等路径；验证 subuid/subgid、SELinux 和用户网络 | 仍引入受管 VM，价值要能覆盖额外层级 |
| macOS/Windows 为主 | 必须治理 Podman Machine、连接和 VM 资源 | 桌面产品直接治理 VM、设置和升级，但仍需明确引擎 |
| 工具硬依赖 Docker API | 逐 API 验证 Podman service；不保证完整等价 | 选择 Moby，保留 Docker API 与 CLI 路径 |
| 团队接受 containerd/nerdctl | 不是 Podman 的原生控制模型 | 选择 containerd，并显式管理 namespace |
| 需要本地 Kubernetes | 另选明确的本地集群工具，避免把容器运行时选择绑死 | 内置可选 Kubernetes，但资源、context 和数据成为额外控制面 |
| 希望用 systemd 管理 Linux 服务 | Quadlet 与用户/系统 unit 形成直接路径 | VM 内状态不宜替代宿主正式服务管理 |
| 需要组织锁定桌面设置 | 依靠 OS 配置、containers.conf 和机器管理 | deployment profile 能提供 defaults/locked 控制 |
如果项目大量使用 Docker Desktop 扩展、Docker API 专有行为或厂商只验证 Moby，选择 Podman 前必须接受适配成本。反过来，如果团队的目标是 Linux rootless 和 systemd 服务，Rancher Desktop 的桌面 VM 可能增加了并不需要的控制层。
比较矩阵必须绑定证据
| 维度 | Podman | Rancher Desktop | 验收证据 |
|---|---|---|---|
| 宿主执行 | Linux 直接；macOS/Windows 经 Machine | 三平台均由产品管理 Linux 环境 | 进程、VM、连接、CPU/内存/磁盘清单 |
| 权限 | rootless 用户命名空间是主要差异 | 权限受宿主、VM、选定引擎和 privileged service 共同影响 | UID/GID、bind mount 正反实验 |
| API | Podman API 提供 Docker compatibility | Moby 提供 Docker API；containerd 不提供 | Testcontainers/IDE 的真实 API 夹具 |
| Compose | 外部 Provider，必须固定实现和版本 | Moby 路径有 Docker Compose；containerd 路径需验证 nerdctl compose 语义 | config、health、错误传播、volume 保留 |
| 镜像状态 | 按用户/rootful/Machine 连接分离 | 按 containerd namespace、Moby 与可能的 store 分离 | 切换前后 image list 与 Digest |
| 网络 | rootless backend 与用户态转发影响行为 | VM 转发、宿主防火墙与引擎共同决定 | 出网、DNS、宿主回连、端口冲突 |
| 生命周期 | CLI、systemd 用户服务、Quadlet、Machine | GUI/rdctl、VM、引擎、Kubernetes、snapshot/reset | 重启、停止、删除与恢复演练 |
| 组织治理 | 包源、containers.conf、用户策略与主机配置 | deployment profile、Allowed Images、产品升级策略 | 锁定字段反证、批准镜像正反例 |
表格不是评审结论。每一行都要链接到命令输出、日志或夹具，否则只是把产品介绍换成了打分表。
迁移基线先在旧运行时冻结
从 Docker 迁移前保存当前项目模型和产物，而不是只保存版本号：
docker version
docker context show
docker compose config > .te05-old-compose.yaml
docker image ls --digests > .te05-old-images.txt
docker volume ls > .te05-old-volumes.txt
docker network ls > .te05-old-networks.txt同时记录构建产物摘要、测试结果、健康检查、端口、日志、命名卷恢复步骤和停止后的进程/端口状态。凭证、内部地址和个人目录需要脱敏，不能把迁移证据包变成新的泄露源。
用同一组正反夹具跑候选
候选运行时使用同一张证据表，不能各挑擅长的演示：
| 阶段 | 正向证据 | 反向证据 |
|---|---|---|
| 获取与构建 | 空缓存按批准 Digest 拉取；同一 Dockerfile 的关键产物与镜像元数据对齐 | 未批准 Registry、错误 Digest 或缺少 CA 时明确失败 |
| 进程与网络 | 非 root 容器端口、日志、退出码和信号停止成立 | 端口冲突非零退出，停止后端口释放 |
| 文件与数据 | bind mount 与 named volume 在重启、重建后保持预期数据 | 错误 UID/标签拒绝写入，普通 down 不删除卷 |
| Compose 与 API | 归一化模型、健康状态和真实 IDE/测试库通过 | Provider 漂移、缺失 API 或失败服务不能伪装成功 |
| 企业网络 | 代理、CA、私有 Registry 和 VPN 条件下重复构建 | 凭证不入库，关闭 TLS 不能成为修复路径 |
| 退出清理 | 限定名称夹具全部回收 | 其他项目的容器、镜像和卷继续存在 |
Podman 结果进入Podman 工程手册记录；Rancher Desktop 结果进入Rancher Desktop 工程手册记录。比较页只保存差异、停止条件和迁移结论，不复制两篇产品教程。
停止条件比“成功率”更重要
迁移停止条件也要可直接判定：
| 触发器 | 为什么必须停止 |
|---|---|
| 核心 Docker API 无法稳定支持且没有批准替代实现 | 项目入口已经失去功能等价性 |
| bind mount、UID/GID、SELinux 或文件事件只能靠提权/关闭安全控制通过 | 候选把兼容成本转化成宿主风险 |
| Compose Provider、namespace 或 image store 无法在团队机器上固定 | 同一配置不再具有稳定解释 |
| 关键数据卷未完成备份恢复，或 owner 无法解释切换后的数据位置 | 回滚会把数据安全交给运气 |
| 凭证必须入库、进入镜像或全局关闭 TLS | 供应链与身份边界已经被破坏 |
| 停止后端口、子进程或 VM 不能回收，只能全局 prune/reset | 生命周期没有形成可逆闭环 |
这不是保守主义。迁移的收益只有在故障与退出成本也可控时才成立。
回滚必须保留旧运行时的可启动性
迁移变更拆成可逆层：工具安装、默认连接、项目命令入口、Compose 差异、CI 夹具和团队文档分别提交。不要在同一个变更里删除旧配置、升级镜像、重写网络并迁移数据。
回滚包由四组材料组成。入口材料保存旧运行时安装来源、支持版本窗口、context/socket 与启动命令；模型材料保存迁移前的 Compose 归一化输出；状态材料保存镜像 Digest、Registry 路径、命名卷导出和恢复演练；退出材料说明怎样撤回新环境变量、socket 与 IDE 配置，并只清理新运行时的限定夹具和 VM。
重要镜像与数据不应只存在 Podman Machine 或 Rancher Desktop VM 中。运行时切回后，从 Registry 和备份重建，比复制内部磁盘更可靠。
架构决策要写清“为什么不是另一个”
决策记录不要写“Podman 更安全”或“Rancher Desktop 更兼容”这种无边界结论。更有效的写法是：
团队 Linux 开发机占主导，服务不依赖 Docker 专有 API；rootless bind mount、Compose Provider 和 Testcontainers 夹具已通过，因此选择 Podman。macOS/Windows 通过受控 Podman Machine 支持。若 API 回归无法在一个升级窗口内解决，回滚至 Moby。
或者：
团队 Windows/macOS 占主导，现有测试与 IDE 依赖 Docker API，同时需要组织锁定桌面设置；因此选择 Rancher Desktop 的 Moby 路径并关闭未使用的 Kubernetes。containerd 仅保留实验环境，不允许开发者日常切换。
明确支持矩阵、排除项、owner、复审事件和回滚触发器，才能让选型结论在换机器、换维护者后仍可解释。
迁移完成的证据
新开发机从零安装后，能说明 CLI、VM/daemon、用户、namespace/store、Compose Provider、网络、卷和 Registry 的实际位置。同一提交在本地与 CI 运行同一入口，关键产物、测试、端口和退出码一致。故障夹具在正确层非零退出，日志不泄露凭证。
旧运行时仍能在回滚演练中按记录恢复，重要镜像和数据不依赖某台桌面 VM。新运行时的升级、停止、数据导出、凭证撤销和卸载分别有 owner；清理脚本只处理明确 label/project 和 te05-* 对象，不包含无范围 prune 或 reset。