Flyway 默认不支持 XML 迁移脚本，仅原生识别 SQL 和 Java 文件；因其设计强调简单、可靠、可审计，而 XML 缺乏标准迁移语义且无内置解析器。
Flyway 默认不支持 XML 格式的迁移脚本，它原生只识别 SQL（.sql） 和 Java（.java） 两类迁移文件。XML 文件（如 .xml）会被 Flyway 忽略，不会被扫描、解析或执行。
为什么 Flyway 不支持 XML 迁移脚本
Flyway 的设计哲学是“简单、可靠、可审计”——SQL 脚本直观、数据库无关性可控、版本回溯清晰。XML 通常用于配置或描述性内容（比如 MyBatis 的 mapper），不是标准的数据库变更载体。Flyway 没有内置 XML 解析器，也不定义 XML 的迁移语义（比如哪个标签代表 CREATE、哪个代表 INSERT），因此无法直接运行 XML 作为 migration。
如果非要使用 XML 文件做数据库变更，可行方案
你不能让 Flyway 直接执行 XML，但可以绕过限制，把 XML 内容“转化”为 Flyway 能识别的形式：
-
方案一：用 XML 存储 SQL 片段，再由构建工具（如 Maven）预处理生成 .sql 文件
例如，写一个changelog-v1.xml，里面用自定义结构存 DDL：CREATE TABLE user (id BIGINT PRIMARY KEY);
配合 Maven 插件（如 `xml-maven-plugin` 或自定义 Groovy 脚本）在编译前解析该 XML，输出对应V1__create_user_table.sql到src/main/resources/db/migration/，再交由 Flyway 执行。 -
方案二：用 Java Migration 封装 XML 解析逻辑
编写一个 Java 迁移类（实现JavaMigration接口），在migrate()方法中读取 classpath 下的 XML 文件，用 DOM/SAX/JAXB 解析出 SQL 语句，再通过JdbcTemplate或Connection执行。注意：需自行保证语句顺序、事务边界和幂等性。 -
方案三：放弃 Flyway，换用支持 XML 的工具（不推荐）
如 Liquibase 原生支持 XML/YAML/JSON 格式的 changelog（databaseChangeLog）。但切换意味着重构迁移历史、适配新语法、重新学习运维方式，通常得不偿失。
更推荐的做法：坚持用标准 SQL 脚本
绝大多数场景下，直接写 SQL 更安全高效：
- 文件名遵循 Flyway 命名规范（如
V1__init_schema.sql、V2__add_email_to_user.sql） - SQL 内容保持纯 DDL/DML，避免数据库特有语法（或用
/* +flyway:sql */注释标注方言） - 复杂逻辑（如批量插入、条件判断）可用存储过程 + SQL 调用，或拆成多个小迁移
- 若需复用 SQL 片段，可用构建时模板引擎（如 FreeMarker）生成最终 .sql 文件
不复杂但容易忽略：Flyway 的能力边界很明确——它不是通用脚本引擎，而是专注数据库版本控制的轻量工具。用对格式，才能少踩坑。
