liquibase 的 tag 是数据库状态快照标记，changeset 是不可变变更单元；回滚依赖 rollback 命令配合 tag 或时间点，需每个 changeset 明确定义 rollback 逻辑且不修改已部署 changeset。
Liquibase 的 tag 和 changeset 版本标记不是同一类机制，但协同使用可支撑可控回滚。tag 是对某次 update 执行后数据库状态的快照标记，不改变 changeset 本身；changeset 则是不可变的变更单元，靠 id/author/filepath 唯一标识。真正支持“按版本回滚”的核心是 rollback 命令配合 tag 或标签范围，而非修改或删除已部署的 changeset。
用 tag 标记关键发布节点
在每次上线完成、验证通过后，立即打 tag，相当于给数据库状态拍一张“可信快照”：
- 执行
liquibase tag v1.2.0（建议用语义化版本号） - tag 名称区分大小写，且不能含空格或特殊字符（如
v1.2.0-rc1合法，v1.2.0 rc1会报错） - tag 仅记录当前 DATABASECHANGELOG 表中最新一条记录的 datetime 和 author 等上下文，不保存数据或结构副本
- 一个数据库可有多个 tag，但同一名称只能存在一个——重复执行会覆盖原 tag 时间戳
基于 tag 回滚到指定状态
回滚操作本质是逆向执行自目标 tag 之后部署的所有 changeset（前提是每个 changeset 都定义了 rollback）：
-
liquibase rollback v1.1.0：回滚到 tagv1.1.0对应的状态（不含该 tag 之后的任何 changeset） -
liquibase rollbackCount 3：回滚最近 3 个 changeset（不依赖 tag，但需确保它们都支持 rollback） -
liquibase rollbackToDate "2024-05-20T14:30:00"：回滚到指定时间点前的状态（精度为秒，依赖 DATABASECHANGELOG 中的 DATEEXECUTED 字段） - 注意：rollback 不会删除已打的 tag，也不会影响更早的 tag；它只修改数据库结构/数据，并更新 DATABASECHANGELOG 表中的
MD5SUM和ROLLBACK相关字段
changeset 的版本控制与 rollback 编写要点
changeset 本身没有“版本号”，其稳定性依赖唯一性 + 显式 rollback 定义。若未提供 rollback 逻辑，对应 changeset 就无法参与 tag 回滚流程：
- 推荐始终使用
<rollback></rollback>标签（XML）或//rollback注释（SQL 格式），哪怕只是DROP TABLE或DELETE FROM xxx WHERE ... - 避免使用
validCheckSum或手动修改 MD5SUM 绕过校验——这会破坏 Liquibase 的完整性保护，导致后续 update 失败 - SQL changeset 中，若含多条语句，请用
--rollback精确标注每条 rollback 语句位置，Liquibase 按注释块解析，不依赖顺序猜测 - 对于无法自动逆向的操作（如
INSERT INTO config VALUES ('new_feature', 'on')），应在 rollback 中补充业务判断逻辑（例如加 WHERE 条件限定删除范围）或改用preConditions控制执行前提
生产环境回滚的实用建议
真实场景中，单纯依赖 tag rollback 往往不够，需结合流程与防护措施：
- 在 CI/CD 流水线中，将
liquibase tag作为部署成功的最后一个步骤，并同步记录 Git commit hash 与 tag 关系 - 回滚前务必先执行
liquibase futureRollbackSQL --tag v1.1.0，生成预览脚本，人工审查逻辑是否安全（尤其涉及 DROP、TRUNCATE、DELETE） - 禁止在生产库直接运行无预览的
rollback；高危操作建议搭配备份快照（如 mysqldump / pg_dump）再执行 - 若某次发布包含多个相互依赖的 changeset，但只想回滚其中一部分，应避免使用 tag rollback，改用
rollbackOneChangeSet并精确指定 id+author+filepath
