生产部署记录只写 latest，过一段时间可能无法确认当时运行的是哪个镜像。标签可以被重新指向，回滚需要的是可识别且仍然可取得的具体产物。
区分标签便利性与版本证据
团队可以使用可读标签组织版本，但应同时记录镜像摘要、源码提交和构建任务。部署说明需要精确到实际产物，不能把某个标签当前指向的内容当成历史部署内容。
为保留策略考虑恢复需求
仓库清理时，确认正在运行和约定回滚窗口内的镜像不会被删除。保留多少版本取决于发布频率、磁盘和恢复目标，不应只按“超过几天就清理”机械处理。
旧产物仍需环境兼容
找得到旧镜像，只解决了程序恢复的一部分。旧版本能否读取当前数据库、使用当前配置与凭证，还要单独验证。回滚说明应标注不可逆变更或需要补偿的业务状态。
验收从记录恢复
选择一个历史部署，让非原操作人员根据记录找到镜像并在受控环境运行，验证关键业务。若需要凭记忆猜测标签，版本追溯还没有真正建立。
常见问题：镜像摘要固定后就不需要更新了吗？
仍需定期评估依赖与基础镜像更新，只是更新应形成新的可验证产物，而不是悄悄改变旧版本含义。
技术参考：Docker：镜像构建实践。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的 .NET 应用还缺少可重复的部署、观察或恢复流程，可以通过容器化与自动化交付服务梳理现状，约定实施内容、演练场景与运维交接方式。