Spring Boot整合Flyway切换WAR与IDE运行模式时全库被覆盖问题

我来帮你拆解下这个让人头疼的问题——其实这大概率和嵌入式Tomcat关系不大，更可能是Flyway的元数据表识别、脚本路径差异或者配置细节出了问题。咱们一步步来排查：

核心排查方向1：确认两种运行模式连接的是同一个数据库 #

这是最容易忽略的关键点：

• 仔细核对STS和命令行运行时的数据库配置，有没有可能STS里激活了额外的Spring Profile（比如dev），加载了application-dev.properties这类配置文件，导致连接的数据库和WAR包不一样？
• 直接登录数据库查看flyway_schema_history表：如果两种模式下操作的是不同库，那自然会各自执行一遍脚本。如果是同一个库，但表里出现了重复的脚本记录，那说明Flyway没有正确识别已执行的迁移。

核心排查方向2：Flyway配置的细节问题 #

你的配置里有几个点可能导致异常：

• 占位符配置冲突：你设置了spring.flyway.placeholder-prefix=$和spring.flyway.placeholder-suffix=$，如果你的迁移脚本里包含$符号（比如SQL变量、存储过程里的语法），Flyway会把它当成占位符尝试解析，导致脚本内容被修改，最终Flyway认为这是一个新的脚本，重复执行。建议改成默认的${}或者其他不冲突的符号，比如：

  spring.flyway.placeholder-prefix=${
  spring.flyway.placeholder-suffix=}
  

• 基线配置的匹配问题：你设置了spring.flyway.baseline-version=1.3，但baselineOnMigrate=true的作用是：当数据库已有表但无flyway_schema_history表时，会将现有 schema 基线化为指定版本，跳过低于该版本的迁移脚本。如果你的迁移脚本版本高于1.3，Flyway还是会执行这些脚本；如果脚本版本命名不规范（比如没有按Vx__xxx.sql的格式），Flyway也无法正确识别已执行的迁移。
• mixed模式的风险：spring.flyway.mixed=true允许混合版本化和未版本化的迁移脚本，如果你所有脚本都是版本化的，建议关闭这个属性，避免Flyway误判未版本化脚本重复执行。

核心排查方向3：类路径与脚本加载的差异 #

STS和命令行运行WAR时，类加载机制有细微差别：

• STS通常直接读取源码目录下的db/migration/testissue脚本，而WAR包是读取编译后打包进JAR/WAR的资源文件。要确认两种环境下的脚本内容、版本号完全一致，有没有STS里脚本被修改但未同步到WAR包的情况？
• 开启Flyway的DEBUG日志，添加配置：

  logging.level.org.flywaydb=DEBUG
  

  查看两种运行模式下的日志，重点看Flyway如何扫描脚本、识别元数据表，有没有出现类似Found unapplied migration script的日志，这能帮你定位Flyway为什么认为脚本需要重新执行。

快速验证步骤 #

1. 先在数据库里手动创建flyway_schema_history表，执行一次基线命令（或者直接插入一条基线记录），再分别用STS和命令行启动应用，看是否还会重复执行脚本。
2. 暂时移除spring.flyway.cleanOnValidationError=true，避免Flyway自动清理数据库，方便你保留元数据表的记录进行对比。

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