在数据库版本控制工具Liquibase中，变更日志（changelog）支持多种格式，其中XML和YAML是最常用的两种。它们本质上都能表达同样的changeset语义，但在书写方式、工具支持和团队协作体验上存在明显区别。选择哪一种，往往取决于项目规模、成员习惯以及自动化程度。
一、语法结构对比
XML格式使用明确的标签嵌套来描述数据库变更，每一个变更类型都对应一个标签，例如<createTable>、<addColumn>。这种写法虽然标签较多，但结构非常清晰，编辑器可以依靠XSD schema提供自动补全和校验。对于复杂变更，比如带约束、默认值、多条注释的建表语句，XML的层级不容易产生歧义。
YAML则依靠缩进表达层级关系，使用键值对描述变更属性。同样的逻辑在YAML里行数更少，看起来更接近配置文件的风格。不过YAML对缩进极其敏感，一个空格错位就会导致解析错误，而且某些编辑器对Liquibase YAML的提示能力不如XML完善。下面分别给出两种格式创建表的示例。
<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.20.xsd">
<changeSet id="1" author="dev">
<createTable tableName="user">
<column name="id" type="bigint">
<constraints primaryKey="true" nullable="false"/>
<column name="name" type="varchar(50)">
<constraints nullable="false"/>
</column>
</createTable>
</changeSet>
</databaseChangeLog>
databaseChangeLog:
- changeSet:
id: 1
author: dev
changes:
- createTable:
tableName: user
columns:
- column:
name: id
type: bigint
constraints:
primaryKey: true
nullable: false
- column:
name: name
type: varchar(50)
constraints:
nullable: false
二、工具链与生态支持
Liquibase官方对XML的支持历史最久，相关文档、示例和社区问答绝大多数基于XML。很多代码生成工具、IDE插件在解析XML changelog时更加稳定，也能直接根据XSD验证文件合法性。如果团队使用自动化流水线批量生成变更日志，XML通常是默认输出格式。
YAML在近年才被广泛接受，虽然Liquibase核心已经良好支持，但部分第三方可视化工具或老旧插件对YAML的兼容性不如XML。此外，当changelog需要被其他语言服务读取时，XML的DOM解析模型比YAML的缩进模型更容易做程序化修改。下面的表格总结了二者在工具层面的差异。
| 维度 | XML | YAML |
|---|---|---|
| 官方文档示例 | 丰富 | 较少但够用 |
| 编辑器校验 | XSD强校验 | 依赖插件 |
| 自动生成友好度 | 高 | 中 |
| 人工可读性 | 中 | 高 |
三、重构与团队协作成本
当项目演进到几十个changeset以后，重构频率会明显上升，比如统一修改某类列的约束或拆分大文件。XML因为标签闭合明确，使用正则或XSLT批量处理更可靠；YAML虽然写时轻松，但批量脚本稍不注意就会破坏缩进，反而增加维护风险。
从团队协作看，新手阅读YAML上手更快，但提交代码时容易因编辑器 Tab 设置不同引入不可见格式错误。XML显得啰嗦，却能让评审者快速定位变更边界。如果团队已经习惯JSON类配置，YAML阻力更小；如果组织强调流程规范和机器校验，XML更合适。
结论上，没有绝对更好的格式：轻量项目、强可读性需求选YAML；复杂仓库、强工具链依赖选XML。
四、混合使用建议
Liquibase允许在一个项目中通过<include>或对应的YAML include语法混合引用不同格式的changelog。这样可以在核心模块用XML保稳定，在边缘服务用YAML提效率。需要注意的是，混合格式会增加新人理解成本，应配套清晰的目录约定。
实施时建议把格式选择写进团队规范，避免同目录出现多种风格混杂。无论选哪种，changeset的id和author规则必须统一，否则会出现重复执行或冲突。下面给出一个XML引入YAML子文件的写法片段。
<databaseChangeLog
xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.20.xsd">
<include file="changelog/2024-init.xml"/>
<include file="changelog/2024-feature.yaml"/>
</databaseChangeLog>
综合来看，格式之争核心是可维护性与书写效率的权衡。先小范围试点，再依据实际报错率和评审耗时做决定，比单纯对比语法更靠谱。