Spring Boot：Flyway迁移晚于MyBatis初始化的问题解决咨询

嘿，太懂你这个踩坑的感受了——@PostConstruct里的数据库代码跑起来的时候，Flyway还没完成迁移，直接报表不存在的错误，简直头大。

问题本质 #

你观察得没错，FlywayAutoConfiguration确实标注了@AutoConfigureAfter({DataSourceAutoConfiguration.class, ...})，但这只保证Flyway在数据源配置好之后启动，没约束MyBatis的初始化顺序。MyBatis的自动配置默认只依赖数据源，所以经常会和Flyway并行启动，甚至更早，导致你的数据库操作跑在迁移之前。

不用重写Flyway配置！更简单的解决方案 #

你完全不需要去重写FlywayAutoConfiguration，有几个更优雅的办法来调整顺序：

方案1：让MyBatis等Flyway跑完再初始化 #

创建一个空的配置类，用@AutoConfigureAfter指定MyBatis的配置要在Flyway之后执行：

@Configuration
@AutoConfigureAfter(FlywayAutoConfiguration.class)
public class MyBatisFlywayOrderConfig {
    // 啥都不用写，就是用来告诉Spring Boot调整初始化顺序的
}

这个类会让Spring Boot把MyBatis相关的自动配置（比如MybatisAutoConfiguration）的启动时间延后到Flyway完成之后，这样你的@PostConstruct方法自然就会在迁移完成后执行了。

方案2：监听Flyway迁移完成事件（更灵活） #

如果你的@PostConstruct逻辑比较特殊，或者想更精准控制时机，可以监听Flyway的迁移完成事件，事件触发后再执行你的数据库操作：

@Component
public class PostMigrationTask {

    @Autowired
    private YourBusinessMapper yourMapper;

    @EventListener(FlywayMigrationCompletedEvent.class)
    public void runPostMigrationJobs() {
        // 把原本@PostConstruct里的数据库操作挪到这里
        yourMapper.initSomeData();
    }
}

这种方式完全绕开了初始化顺序的问题，直接绑定到Flyway迁移完成的节点上，稳得一批。

方案3：检查Flyway的启动配置（兜底） #

如果上面两个方案都没生效，先检查下你的配置文件，确保Flyway是在启动时自动执行迁移的：

# application.properties
spring.flyway.enabled=true
spring.flyway.migrate-at-startup=true # 这个默认是true，但如果被覆盖了要重新打开
spring.flyway.baseline-on-migrate=true # 第一次启动时自动创建基线，避免无历史记录报错

这个配置是Flyway默认开启的，但如果你的项目有自定义配置把它关了，重新打开就行。

怎么验证生效？ #

启动应用后看日志：

• 先找Flyway的迁移日志，比如Successfully applied 2 migrations
• 再看MyBatis的初始化日志，比如Scanned 5 mappers
• 或者看你迁移后执行的逻辑日志，是不是在Flyway日志之后出现

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