9.3 场景选型：什么时候选谁
9.3 场景选型：什么时候选谁
本节摘要：把全册的对比收敛成一张按部署形态组织的选型决策表：个人开发机、CI 流水线、多租户共享服务器、边缘节点、K8s 集群节点，每种形态给出推荐、核心理由与反例条件。选型表的价值在于让"留在 Docker"也有清晰的尊严——它不是失败，是场景匹配。
决策表：六种部署形态的推荐
| 部署形态 | 推荐 | 核心理由 | 反例条件（留在 Docker） |
|---|---|---|---|
| 个人开发机 | Podman（或维持现状） | rootless 免 sudo、无后台进程、alias 兼容 | 重度依赖 Docker Desktop 的 GUI 生态与文件共享 |
| CI 构建节点 | Podman | 无 socket 越权、无特权构建（第 3.1 节） | 构建强依赖 Docker 专有 API 字段且无改造预算 |
| 多租户共享服务器 | Podman rootless | UID 映射隔离租户、无共用 root 管理面 | 无（这个场景 Docker 只有缓解手段没有根治） |
| 边缘与单机服务器 | Podman 加 Quadlet | 容器进 systemd 依赖图、断电自愈（第 7 章） | 团队只有 Docker 运维经验且无学习窗口 |
| GPU 与设备直通 | 视情况 | rootless 设备访问繁琐是 Podman 的弱项 | 直通需求重时留在 Docker 省心（9.1 节的真实例外） |
| K8s 集群节点 | 集群运行时的事 | Podman 只在本地与边缘有意义，别装在 kubelet 节点上抢角色 | — |
表格之外补一条元原则：选型的单位是场景，不是信仰。同一个团队完全可能 CI 用 Podman、GPU 工作站用 Docker、边缘服务器用 Podman——第 9.1 节的迁移案例里就保留了这样的例外。混合不是不彻底，是对每个场景负责任。
决策表还有个使用方式上的提醒：它是快查工具，不是论证替代品。表格里每一行的"核心理由"都指向本册某一节的机制讨论（括号里的章节号就是证据链入口），评审现场有人质疑某行结论时，正确的动作是翻开对应章节把机制讲一遍，而不是回到"我觉得"。决策表的价值恰恰在于它把分歧收敛到了可以查证的位置——一张好表让讨论从立场层降到事实层。
按需求轴的三道快问快答
决策表的浓缩版，适合放在技术评审的讨论桌上：
问题一：你的容器要不要跑在"不属于你的机器"上？（共享服务器、高校集群、托管环境）要，则 rootless Podman 几乎是唯一正经答案——没有 root 权限的机器上，Docker 直接不可用，而 rootless Podman 在用户空间自洽（第 2.2 节的映射机制是全部底气）。
问题二：你的工作流里有没有"必须给容器递 root"的环节？（socket 挂载、特权容器、设备直通）有，且无法改造，则 Docker 的"顺手"是真实便利；能改造（大多数 CI 场景都能，第 9.1 节的样板戏），则改造后的 Podman 方案同时消除了安全隐患。
问题三：运维的终点形态是什么？（单机服务化、上集群、纯开发用）单机服务化选 Podman 加 Quadlet（第 7 章的依赖图红利独此一家）；上集群则开发侧用 Podman 加 play kube 有验证优势（第 8 章）；纯开发用则两者体感差异最小，跟团队习惯走。
两个方向的"后悔药"
给犹豫者两边各留一颗。已迁 Podman 想回：成本极低——镜像本就互通（OCI 标准），compose 文件双轨维护，Quadlet 停用即回旧单元（第 9.1 节的回退设计原样可用）。留在 Docker 想试：成本同样低——alias 双轨零风险试点，一台机器半天就能跑完全册第 2、5 章的验证清单。双向的低成本试错是这个技术领域难得的友善属性，比"论证该不该"更好的动作是"跑一个试点再论证"。
补一句关于试点的操作建议，它常被做歪：试点要选"有代表性但不出名"的项目——太边缘的项目（一个 hello world）验证不了任何真实差异，太核心的项目（支付主链路）出了问题会直接否决整个迁移提案。合适的试点长这样：有三到五个容器、有一个数据卷、有一条 CI 构建链路、出问题影响面可控。给试点定两周窗口、四个通过标准（命令兼容、compose 兼容、卷权限、服务化各一），到点无论结论如何都出一份书面报告。试点的价值不在"证明应该迁"，而在用最小成本把决策从"观点之争"变成"数据之争"。还有一条纪律同样重要：试点期间发现的问题要区分"引擎差异"与"配置疏忽"——前者是决策输入，后者只是要在正式迁移时避免的作业错误，混在一起报告会让数据失真。
一个完整案例：给技术委员会的选型报告
背景：公司技术委员会要求容器引擎选型给出书面结论，各团队场景混杂。操作：不写立场文，写场景表——把六个团队的部署形态逐个套进上面的决策表，各得推荐与理由；两台多租户构建服务器（场景三）与一条 CI 流水线（场景二）推荐迁移，GPU 训练集群（设备直通）明确留在 Docker，其余场景标注"现状可维持、新机器按推荐装"。结果：报告一次通过，争议消失——因为每个结论都锚在具体场景与可验证的差异上（各章的知识点即证据链），而不是品味之争。解读：选型报告的写法比结论更重要；把"差异→机制→场景匹配"的推理链摆出来，反对者也只是在反对推理链的某一环，讨论就有了着力点。变式：如果委员会要求单一标准，就按"占比最高的场景"定默认引擎，其余场景走例外审批——默认加例外的治理成本远低于一刀切。
本节要点回顾
- 选型单位是场景：六种部署形态各有推荐与反例条件，混合部署是常态
- 决策表是快查工具：每行理由指向具体章节的机制讨论，分歧收敛到可查证的位置
- 三问快答：不属于你的机器、必须递 root 的环节、运维终点形态
- 多租户与无 root 是 Podman 的硬优势：这些场景 Docker 只有缓解没有根治
- 设备直通是 Podman 的弱项：留在 Docker 是诚实选择不是失败
- 双向后悔药都便宜：跑试点比论证该不该更有信息量
- 试点纪律：区分引擎差异与配置疏忽，报告才不失真
- 报告写推理链不写立场：差异、机制、场景匹配三层摆开