Quarkus/Flyway/Postgres升级后校验和差异及迁移检测变更问题咨询

一、初步修复方案的正确性 #

你的初步修复方案是正确的，具体说明：

• 调整flyway_schema_history校验和：使用flyway repair命令是官方推荐的安全方式，它会自动修复schema_history表中与本地脚本不匹配的校验和，相比手动修改表数据，能避免人为错误。
• 添加生产环境专属配置排除dev目录：生产环境本就不应加载仅用于开发/预发布的迁移脚本，通过专属配置明确排除dev目录，能从根源上避免后续出现dev脚本无序执行的问题，符合环境隔离的最佳实践。

二、更新前生产与其他环境行为差异的根因 #

结合你提供的依赖版本变更和环境差异，主要原因可从以下两方面分析：

1. dev目录未加载的原因 #

旧版本组合（Flyway 9.4.0 + Quarkus 2.11.3.Final）在谷歌托管生产环境中，存在隐式配置覆盖的可能：

• Quarkus 2.x的生产Profile（quarkus.prod）默认会对Flyway配置做优化，可能自动排除带有dev标识的资源目录，而自托管预发布环境未启用严格的生产Profile，因此保留了dev目录的加载。
• 谷歌托管平台可能通过环境变量或平台配置，隐式注入了flyway.locations参数，覆盖了你的自定义配置，仅保留common目录，而自托管环境没有这类平台级的配置注入。

2. 校验和稳定差异的原因 #

旧版本依赖组合的校验和计算逻辑存在环境相关的细微差异：

• 文件内容的隐性差异：生产环境中SQL文件的打包或存储方式可能导致内容与其他环境不同，比如换行符格式（Windows CRLF vs Unix LF）、打包过程中自动添加的空白字符或注释差异，Flyway 9.x对这些细节高度敏感，会计算出不同的校验和。
• 驱动与框架的交互差异：旧版PostgreSQL驱动（42.4.2）在谷歌托管环境中可能有不同的SQL解析行为，结合Quarkus 2.11.3.Final的生产环境预处理逻辑（比如自动去除SQL注释、格式化语句），导致Flyway读取的SQL内容与预发布环境不一致，最终产生不同的校验和。

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