容器更新常被实现为拉取新镜像并替换实例，但生产发布还需要证明新旧版本身份明确、运行配置可追溯、数据格式兼容，且出现问题时能恢复到已验证状态。回滚不是简单地重新启动旧容器：旧镜像可能已被清理，配置可能已变化，数据库结构也可能已前进。发布设计要把这些依赖纳入同一变更记录。🚀
可变标签如latest可能在不同时间指向不同镜像，难以作为审计和恢复依据。建议部署记录保存镜像摘要、源码提交、构建流水线记录、依赖锁文件版本和配置版本。部署时使用可验证的不可变镜像标识，确保回滚时取到的内容与当初发布的内容一致。
镜像保留周期应覆盖发布观察期、故障发现窗口和组织规定的追溯期限。仓库清理规则若删除了仍可能需要回滚的镜像，文档中的回滚命令就失去意义。应定期在目标环境验证旧摘要仍能拉取，并确认所需基础镜像、启动参数和配置也仍可获得。📦
滚动更新期间，新旧实例可能同时处理请求并访问同一数据库。数据库迁移应优先采用“扩展、迁移、收缩”次序：先新增兼容结构，新旧程序都能读写；逐步迁移数据并验证；待旧版本彻底退出后，再考虑移除旧字段或索引。这样应用版本回退时，旧程序仍可理解当前数据结构。
若迁移会重命名字段、改变编码或删除旧列，应用回滚可能无法读取新数据。对无法保持兼容的迁移，应把数据库恢复方案、数据丢失窗口和停机窗口作为发布决策的一部分。应用镜像回滚不会自动撤销数据库写入或迁移。🧩
先让有限实例或流量使用新版本，再根据业务风险扩大范围。观察指标应包含请求错误率、延迟分位数、重启次数、资源使用、依赖连接失败和关键业务结果。发布门槛要定义数值阈值、观察时长及基线，例如错误率相对发布前基线上升并持续多个采样窗口时暂停扩量。瞬时单点抖动不应自动等同于版本缺陷。
同时核对启动参数、环境配置和密钥版本。旧程序可能不支持新配置字段，新程序也可能要求新参数；切回镜像但保留不兼容配置，仍会启动失败。配置变更应与应用版本关联，敏感值使用受控密钥管理方式，发布记录只记版本或引用标识，不写明文。📊
发布前应明确谁有权暂停或回滚、观察窗口、触发阈值、回滚目标摘要以及涉及的配置和迁移步骤。回滚最好先恢复应用流量和兼容配置，再检查数据状态。若新版本已写入旧版本无法识别的数据格式，则必须有向后兼容写入策略、数据修复方案，或明确不能直接回退的条件。
可用docker inspect CONTAINER查看实际运行的镜像标识和配置摘要；发布系统记录还应能从服务实例追溯到提交与构建信息。不能仅凭镜像标签推断当前运行内容，特别是在标签可被重指向的仓库中。🔎
容易误判：镜像成功切回不代表业务回滚完成。数据库、队列中的新格式消息、缓存和外部副作用都可能保留新版本造成的状态。🛡️
