SQL Liquibase 的 precondition failed 的变更回滚处理模板

precondition failed 表示 liquibase 在执行 changeset 前校验失败，如表不存在、列类型不匹配等，此时未进入执行流程，故不触发自动 rollback；需手动配置 onfail 行为并编写精准 rollback 块。

precondition failed 错误到底意味着什么

不是数据库挂了，也不是 Liquibase 坏了，而是你在 changeSet 里写的 preConditions 没通过校验——比如表不存在、列类型不匹配、sql 查询返回非空结果等。Liquibase 在执行前卡在这一步，直接中断，后续变更不会跑，也不会自动回滚已执行的上一个 changeSet。

为什么 rollback 不会自动触发

Liquibase 的设计原则是「变更即事实」：只要一个 changeSet 成功提交（commit），它就被标记为已执行；precondition failed 发生在执行阶段之前，所以它根本没进入「执行-提交」流程，自然没有「已执行的变更」可回滚。你看到的所谓「回滚失败」，其实是误以为系统该帮你兜底，其实它连兜底的机会都没拿到。

• preCondition 是前置守门员，失败 = 拒绝入场，不产生事务记录
• 真正需要 rollback 的场景，是 changeSet 执行中抛异常（比如 SQL 语法错、约束冲突）
• 如果想让 precondition 失败也触发 rollback，必须手动写 rollback 块并配合外部脚本或 CI 流程控制

实用的 precondition failed 应对模板

别依赖 Liquibase 自动处理，把防御逻辑收归自己手里。常见做法是：用 onFail="MARK_RAN" 或 "HALT" 显式控制行为，并搭配可预测的 rollback 写法。

• 对「检查表是否存在」类 precondition，用 dbms="h2,postgresql" 避免跨库报错，而不是靠 catch-all
• 写 rollback 时，只针对「这个 changeSet 明确创建的东西」逆向操作，不要试图 undo 其他变更
• 示例：你用 createTable 加了个 tmp_user_log 表，且 precondition 是「表不存在才建」，那 rollback 就只写 dropTable tableName="tmp_user_log"，别碰别的
• CI/CD 中遇到 precondition failed，建议 exit code != 0 并人工介入——因为这往往反映环境状态和预期不一致（比如预发环境漏跑了某个基础表）

容易被忽略的兼容性坑

不同数据库对 precondition 的 SQL 支持差异极大，同一段 sqlCheck 在 H2 里过，在 PostgreSQL 里可能因权限或 schema 默认值直接 fail。

• sqlCheck 返回结果必须是单行单列，否则多数数据库驱动会报 ResultSet is closed
• oracle 要求显式加 FROM DUAL，mysql 8.0+ 默认禁用 select count(*) 无 FROM 子句（除非 sql_mode 松）
• 用 tableExists 时，schema 参数在 SQL Server 和 PostgreSQL 中行为不一致：前者默认查 dbo，后者默认查 public，漏写会导致 precondition 总是 false
• 别在 precondition 里调用自定义函数——Liquibase 不保证函数已部署，且跨环境迁移时极易缺失

最稳妥的方式，是把 precondition 的逻辑尽量压到标准 JDBC 元数据查询层面（比如 columnExists），少写裸 SQL。