镜像版本回滚与蓝绿部署可协同使用：回滚保障快速恢复，蓝绿实现零感知切换；需用语义化标签、隔离环境、原子流量切换，并通过自动化闭环验证确保一致性。

镜像版本回滚和蓝绿部署不是非此即彼的选择，而是可以协同使用的发布保障手段：回滚解决“出错了怎么快速恢复”，蓝绿解决“新版本上线时如何零感知切换”。关键在于用好标签（tag）语义、隔离运行时环境、控制流量入口。

用好镜像标签，让回滚有据可依

不要只依赖 latest 标签。它不具确定性，构建覆盖后历史版本即丢失，无法精准回退。

• 每次构建都打带语义的标签，例如 v1.2.3、20240520-prod 或 sha256:abc123...（推荐结合 Git Commit SHA）
• 生产环境部署命令中明确指定标签：docker run -d myapp:v1.2.3，而非 myapp:latest
• 保留至少最近 3 个稳定版本镜像在 Registry 中，配合脚本自动清理过期标签（如超过 90 天且无任何环境引用）

蓝绿部署的核心是环境隔离与流量原子切换

蓝绿不是单纯起两套容器，而是围绕“环境不可变”和“路由可瞬切”设计：

• 蓝环境（当前线上）和绿环境（待上线）各自使用独立的网络命名空间、配置卷、数据库连接池（必要时做读写分离或兼容双写）
• 通过反向代理（如 Nginx、Traefik）或服务网格（Istio）控制流量。切换只需更新 upstream 指向，毫秒级生效
• 健康检查必须真实有效：绿环境启动后，需通过 /healthz 等端点验证服务就绪，再触发流量切流；失败则自动回切并告警

回滚不是“重跑旧命令”，而是闭环验证动作

发现故障后执行回滚，不能只改标签重启，要确保状态一致：

• 确认数据库 Schema 和数据兼容性：v1.2.3 回退到 v1.2.2 前，检查是否有新增字段或迁移脚本不可逆
• 同步回滚配套资源：配置中心（Nacos/Apollo）对应版本、证书、密钥挂载路径等需与镜像版本对齐
• 回滚后立即触发冒烟测试（Smoke Test）：调用核心接口、检查日志关键词、验证监控指标回归基线

自动化是落地前提，手动操作等于高风险

所有关键步骤必须封装进 CI/CD 流水线，避免人为失误：

• 构建阶段自动生成多标签：v${VERSION}、git-${COMMIT_SHA}、build-${BUILD_ID}
• 部署流水线提供“一键蓝绿切换”和“一键回滚至指定标签”按钮，背后执行环境校验 + 镜像拉取 + 容器启停 + 路由更新 + 健康探测
• 每次发布/回滚生成审计日志：谁、何时、从哪版切到哪版、是否通过健康检查、耗时多少