刚好之前从 Liquibase 转 Flyway 踩过类似的坑，来给你详细说清楚这两个问题：

一、Flyway 如何控制迁移顺序？ #

和 Liquibase 靠 XML 配置指定顺序完全不同，Flyway 的迁移顺序完全由文件名前缀决定，不需要额外的配置文件。核心规则是：

• 迁移文件必须遵循固定命名格式：V<版本标识>__<迁移描述>.sql（注意是两个下划线分隔版本和描述）
  示例：V1__create_users_table.sql、V2.1__add_user_phone_column.sql、V202405201430__add_user_index.sql
• Flyway 会按照版本标识的语义化顺序来执行迁移：
  • 纯数字版本：V1 < V2 < V10（Flyway 会拆分版本段做数字比较，不是简单字符串排序）
  • 带小数点的版本：V1.9 < V2.0 < V2.1
  • 时间戳版本：按时间先后排序（最适合并行开发场景）
• 所有执行过的迁移会被记录到自动生成的 flyway_schema_history 表中，Flyway 只会执行未被记录的新迁移。

二、并行添加迁移时的处理方案 #

这正是 Flyway 比 Liquibase 省心的地方，核心思路是让版本标识天然唯一，避免冲突：

推荐方案：用时间戳作为版本标识 #

这是团队并行开发的最优解：

• 每个开发者在创建迁移文件时，用当前时间戳作为版本前缀（比如 V202405201430__xxx.sql，精确到分钟甚至秒）
• 时间戳天然唯一，不会出现两个人选到相同版本号的情况，也就不会有 Git 冲突
• 迁移顺序完全符合代码提交的时间先后，逻辑上也合理

备选方案：数字版本号 + 团队约定 #

如果你们更倾向于用数字版本号：

• 开发前先查看项目中已有的最高版本号（比如当前最高是 V5），自己选下一个未使用的版本（比如 V6）
• 如果并行开发中出现了版本号冲突（比如两个人都提交了 V6），只需要把其中一个迁移文件的版本号改成更高的（比如 V7），然后重新执行迁移即可——Flyway 会按 V6 → V7 的顺序执行，不会有问题

额外提醒：避免手动修改已执行的迁移文件 #

和 Liquibase 一样，Flyway 也不建议修改已经执行过的迁移文件（会触发校验失败），如果需要修正之前的迁移，应该创建一个新的迁移文件来覆盖或调整，而不是直接修改旧文件。

内容的提问来源于stack exchange，提问作者Combo