回滚要保留数据迁移的兼容路径.md

**代码可以回滚到上一个版本,但已经跑过的数据迁移不会自己回滚 —— 所以「回滚」这件事必须在写迁移时就设计好兼容路径,而不是出事时才发现回不去。**

机制

镜像/代码的回滚是换一个 tag(可追踪、可复现),成本极低;数据库结构变更是一次性、不可逆的。两者不对称:

代码回滚:docker pull <上一个 commit SHA> + up -d   ← 秒级
数据回滚:无(除非迁移本身写了向后兼容)

⇒ 旧版本代码若读不懂新结构(或缺列、缺表),回滚就等于把服务打挂。因此:

  • 迁移优先选向后兼容的形态:先加列/加表、双写、再切读,最后才删旧结构。
  • 破坏性变更(删列/改名)要和代码切换分开发布,中间留一个「新旧都能跑」的版本。
  • 回滚步骤必须在发布前就写下来并验证过,不是事后补文档。

相关