发布回滚方案怎么准备？

发布回滚方案要在上线前准备好，不能等线上异常时再讨论。春喜铜知识库和后台系统发布时，回滚对象可能是代码、构建产物、容器镜像、Nginx 配置、证书、数据迁移、栏目入口或导入模板，不同对象的回退方式不一样。

回滚不是“把代码退回去”这么简单。只改内容页面时，Git 版本回退可能够用；如果同时改了配置、数据、附件路径或服务器环境，就要分开判断哪些能回滚、哪些只能补正。

先定义回滚条件

异常类型	判断方式	处理口径
页面不可访问	首页、栏目页、重点页面非 200	优先恢复上一版构建产物或容器
配置异常	HTTPS、Nginx、端口、反向代理异常	回退配置并重新加载服务
数据异常	导入、迁移、主数据或权限异常	先冻结影响范围，再按批次修正
内容异常	页面标题、链接、栏目入口明显错误	快速修正文档并重新发布
现场阻断	客服、生产、仓库无法按新流程操作	临时恢复旧口径或发出降级通知

上线前要写清楚：谁有权决定回滚，回滚到哪个提交或备份，回滚后需要抽查哪些页面，谁通知业务岗位。

回滚底稿要能直接执行

1. 保留上线前提交号、构建产物、部署包、配置备份和关键页面截图或状态。
2. 写清回滚命令、远程目录、容器名称、端口和验证 URL。
3. 涉及数据变更时，单独准备数据回退或补正方案，不和代码回滚混在一起。
4. 回滚前先判断是否需要备份当前异常状态，方便事后复盘。
5. 回滚后重新验证首页、改动页、日志、容器健康和业务入口。
6. 回滚完成要通知受影响岗位，说明继续按旧版本还是等待二次发布。

好的回滚方案不是为了频繁回滚，而是让大家知道出问题时有边界、有责任人、有恢复路径。这样上线时才不会靠临场运气。