为什么用 Flyway
多环境下手工同步表结构迟早出事。Flyway 把 DDL 变成代码的一部分：启动时自动校验并执行未应用的迁移，库结构始终与代码对齐。
迁移脚本命名规范
格式为 V版本号__描述.sql（注意是两个下划线），例如：
db/
├── V2.0.0.0__demo_init.sql # 基线：全库初始化
├── V2.0.0.1__drop_temp_log.sql # 增量：删表
└── V2.0.0.2__drop_unused_table.sql新建脚本前先看目录里已有哪些版本号，避免重复。
最大的坑：基线文件不可修改
已经应用过的迁移脚本，内容永远不能再改。Flyway 会在 flyway_schema_history 表里记录每个脚本的 checksum，启动时校验，对不上就直接拒绝启动：
FlywayException: Validate failed:
Migration checksum mismatch for migration version 2.0.0.0
-> Applied to database : -2077654321
-> Resolved locally : 1096382517我就踩过一次：图省事把一张表从基线里删了，结果下次部署服务起不来。正确做法是新增增量迁移 DROP TABLE，基线内容保持原样。
小结
out-of-order: true 适合多分支并行开发，但上生产前建议关掉。记住一条铁律：迁移文件是只追加（append-only）的，不改历史。