YAML 更适合 Liquibase 日常使用，因其易读易维护、文件体积小约40%、与现代工具链风格一致；XML 仅在需XSD验证、强XML工具链或已有XML解析脚本等特定场景下必须使用。
YAML 格式更适合 Liquibase 日常使用，尤其在开发和协作场景下——它更易读、更易维护、生成的 changelog 文件体积小约 40%，且与 Spring Boot、Kubernetes 等现代工具链风格一致。
为什么 YAML 更适合 Liquibase changelog？
XML 的 <changeSet> 嵌套结构在迁移逻辑复杂时容易视觉混乱，比如一个含多条 <addColumn> 和 <addForeignKeyConstraint> 的变更集，标签闭合错位就可能引发解析失败；而 YAML 用缩进+键值对表达，层级一目了然：
databaseChangeLog:
- changeSet:
id: add-user-table
author: dev
changes:
- createTable:
tableName: user
columns:
- column:
name: id
type: BIGINT
constraints:
primaryKey: true
- column:
name: email
type: VARCHAR(255)相同逻辑的 XML 版本需写 3 倍以上行数，且必须严格匹配 </column>、</columns> 等闭合标签。
XML 还值得选吗？什么场景下必须用？
XML 仍保有不可替代的价值，但仅限于特定约束场景：
- 需要与遗留系统对接（如企业级 ESB、SOAP 中间件），它们依赖 XSD 验证
databaseChangeLog.xsd来校验变更结构 - 团队中存在强 XML 工具链（如 Eclipse + Liquibase 插件 + 自动补全/XSD 提示），且成员不熟悉 YAML 缩进规则
- CI/CD 流水线中已有成熟 XML 解析脚本（例如用
xmllint校验变更集 ID 唯一性），临时切 YAML 可能引入解析兼容风险
注意：Liquibase 本身对两种格式的运行时支持完全等价，liquibase update 不关心底层是 XML 还是 YAML —— 差异只在人写、人读、人改的环节。
实际选型时最容易踩的坑
选 YAML 不代表万事大吉，这些细节常被忽略：
-
缩进必须用空格，不能用 Tab—— VS Code 默认设为 2 空格缩进，但若项目 .editorconfig 未统一，或某人用记事本编辑，一个 Tab 就导致while parsing a block mapping, did not find expected key -
字符串值含冒号或特殊字符时必须加引号，例如defaultValue: "2025-12-24"，否则会被 YAML 解析器误判为 map -
changeSet id 和 author 组合必须全局唯一，XML 中靠标签位置隐式隔离，YAML 中靠缩进+列表顺序，一旦复制粘贴出错，Liquibase 会报ValidationFailedException: Duplicate key - Spring Boot 3.2+ 默认启用
spring.liquibase.change-log=classpath:db/changelog/db.changelog-master.yaml，但若文件名写成.yml（而非.yaml），某些旧版 SnakeYAML 会静默跳过加载
YAML 是 Liquibase changelog 的事实标准方向，但它的“简洁”背后是对格式纪律的更高要求——不是语法难，而是容错低。真正要花时间的，从来不是选格式，而是把 id、author、缩进规范、文件命名约定固化进团队的 PR 检查清单里。
