CI/CD 里固定镜像版本：digest、semver 与 latest 的风险量化

团队争论最多的问题之一：生产环境镜像到底怎么固定？ 本文不给唯一正确答案，只给决策框架：你用 digest、semver 还是（极少数场景）latest，本质是在交换三类能力——可复现、可回滚、可升级。

1. latest：省时，但未必省钱

latest 的最大优势是沟通成本低；最大风险是不可预测变更。在 CI 里使用 latest，等价于把构建稳定性交给上游发布时间线。

适合的场景通常只有：实验环境、快速原型、明确允许漂移的流水线。

2. semver tag：工程友好，但仍可能漂移

很多团队采用 1.2.x 这类标签策略，它比 latest 更可控，但仍可能存在「同 tag 对应内容更新」的 Registry 行为差异（取决于发布策略）。如果你的发布流程强调审计与追责，需要额外机制保证 tag 与构建产物绑定。

3. digest：最强可复现，但升级链路要配套

digest 固定的是内容寻址结果：不可复现问题会显著减少，但升级时需要明确流程：

• 谁来触发更新 digest
• 如何做变更评审（至少包含漏洞扫描与变更说明）
• 如何回滚（准备上一个 digest）

4. 把策略拆成「构建」与「运行」

常见最佳实践是：

• 构建阶段：尽可能固定基础镜像（digest 或明确 minor）
• 运行阶段：Kubernetes/Compose 使用与你风险等级匹配的固定策略

一句话：构建不可复现，运行再稳也难稳。

5. 小结

没有银弹，只有取舍。你们团队的答案是：愿意用多少「升级摩擦」换多少「线上确定性」。把这条规则写进工程规范，比争论 latest 好坏更有意义。