一键回滚需依赖唯一版本标识（如git短sha）、可追溯构建产物归档、原子化切换及手动/自动双通道触发机制。
一键回滚不是“点一下就完事”，而是依赖清晰的版本控制、可追溯的构建产物和确定的执行路径。核心在于让每次发布都自带“退路”，而不是事后补救。
版本标识必须唯一且可定位
回滚的前提是能准确识别“要回到哪”。不能只靠“上一个版本”这种模糊概念，必须用不可变标识锚定每个发布状态：
- 使用 Git 的短 SHA（如 a1b2c3d）作为构建版本号，而非分支名或时间戳——分支会变，时间可能重复，SHA 唯一且绑定代码快照
- 构建产物（如 Docker 镜像、dist 包、模型权重）需携带该 SHA 标签，例如 myapp:a1b2c3d 或 dist-v-a1b2c3d.tar.gz
- 在部署时将版本号写入运行时环境（如 HTTP 响应头 X-App-Version: a1b2c3d），便于线上快速确认当前版本
构建与部署过程必须留痕可溯
没有记录的发布等于没有备份。每次成功部署，系统需自动完成三件事：
- 将本次构建产物（含代码、配置、依赖清单）完整归档到独立存储（如对象存储或专用备份目录），路径按版本号组织，例如 s3://backups/myapp/a1b2c3d/
- 更新部署元数据：记录发布时间、操作人、Git 提交信息、镜像 digest、健康检查结果
- 保留历史版本数量可控（如最多保留 10 个），避免无限堆积，但确保关键版本不被清理
回滚操作必须原子且可验证
回滚不是“覆盖文件”，而是切换到已验证过的稳定状态。执行逻辑应遵循最小变更原则：
- 停止当前服务实例（非强制 kill，先发 graceful shutdown 信号）
- 从归档中拉取目标版本的完整快照（含代码、配置、权重等），校验 checksum 确保完整性
- 加载并启动该版本，不修改任何运行时状态（如数据库迁移不逆向，仅切回兼容旧版的逻辑）
- 启动后自动触发健康检查，全部通过才宣告回滚完成；任一失败则标记异常并告警，不静默失败
支持手动触发与自动触发双通道
人工判断和机器判断应互补，而非互斥：
- 提供简洁界面或 CLI 命令（如 postiz rollback --to a1b2c3d 或 kubectl rollout undo deployment/myapp --to-revision=5），供运维快速干预
- 对接监控系统（如 Prometheus + Alertmanager），当错误率突增、延迟飙升或健康检查连续失败时，自动调用回滚 API，并附带触发原因日志
- 自动回滚前强制执行“安全检查”：确认目标版本存在、未被标记为废弃、与当前环境兼容（如 Kubernetes API 版本匹配）
