17370845950

YAML 更适合 Liquibase 日常使用，因其易读易维护、文件体积小约40%、与现代工具链风格一致；XML 仅在需XSD验证、强XML工具链或已有XML解析脚本等特定场景下必须使用。

YAML 格式更适合 Liquibase 日常使用，尤其在开发和协作场景下——它更易读、更易维护、生成的 changelog 文件体积小约 40%，且与 Spring Boot、Kubernetes 等现代工具链风格一致。

为什么 YAML 更适合 Liquibase changelog？

XML 的 嵌套结构在迁移逻辑复杂时容易视觉混乱，比如一个含多条 和 的变更集，标签闭合错位就可能引发解析失败；而 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 倍以上行数，且必须严格匹配 、 等闭合标签。

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 检查清单里。