jOOQ 生成代码与数据库不一致的根本原因是其仅基于生成时连接的数据库结构生成Java类，若该库未由Flyway完整迁移至最新版本，或存在迁移失败、方言不匹配、类型定义缺失等问题，就会导致代码错位。
为什么 jOOQ 生成的代码总和数据库不一致？
根本原因不是 jOOQ 有问题，而是它只读取当前数据库结构生成 Java 类——如果表是手工改的、或用其他工具（比如 psql）执行的 DDL，jOOQ 不会感知。你跑 generate 任务时连的是空库或旧库，生成的 Tables.java 就天然错位。
- 必须确保
jOOQ代码生成前，目标数据库已由Flyway完整迁移至最新版本（即Flyway的flyway migrate已成功执行） - 开发时推荐把
Flyway的locations设为 classpath 下单一路径（如classpath:db/migration），避免多模块间 SQL 文件散落、版本序号冲突 -
jOOQ的configuration.target.package和Flyway的baseline-on-migrate=true配合使用时要小心：若 baseline 版本高于当前 SQL 脚本版本，jOOQ仍会基于旧结构生成，不会报错但结果不可信
Flyway 迁移失败后 jOOQ 还能生成吗？
不能，而且容易误判。常见现象是 Flyway 报 SQL state [42703]: column "xxx" does not exist，但你检查 SQL 文件发现字段明明写了——其实是上一个脚本里建表语句漏了 COMMIT 或用了错误的方言（比如在 PostgreSQL 里写了 ENGINE=InnoDB），导致 Flyway 认为迁移失败并锁住 flyway_schema_history 表，后续所有操作（包括 jOOQ 连接该库生成）都基于一个半截状态。
- 先运行
flyway repair清理状态（仅限本地/测试环境），再确认数据库实际结构是否与最新 SQL 脚本一致 -
jOOQ的generationTool任务应明确依赖flywayMigrate（Gradle）或绑定到 Maven 的process-resources阶段之前，否则 CI 流水线里可能跳过迁移直接生成 - 不要在
application.yml里配两个数据源分别给Flyway和jOOQ：它们必须指向同一个数据库实例，且该实例需支持INFORMATION_SCHEMA查询（H2 默认开，PostgreSQL 需确保连接用户有SELECT权限）
如何让 jOOQ 正确识别 Flyway 的自定义类型（如 enum、domain）？
PostgreSQL 的 CREATE TYPE xxx AS ENUM 或自定义 DOMAIN 在 jOOQ 默认配置下会被忽略，生成的字段是 Object 或 String，失去类型安全。这不是 bug，是 jOOQ 对非标类型的保守策略。
- 在
jOOQ的generator.configuration.database.includes中显式加上类型名正则，例如.*_type|status_enum - 配合
forcedTypes块，把特定字段映射到 Java 枚举类：<forcedType> <userType>com.example.Status</userType> <binding>com.example.StatusBinding</binding> <expression>order\.status</expression> </forcedType>
- 注意
Flyway的 SQL 脚本中，CREATE TYPE必须放在第一个迁移文件（V1__xxx.sql），否则jOOQ生成时查不到该类型定义
CI 环境里 Flyway + jOOQ 自动化失败的典型卡点
最常发生在 Docker 化构建中：镜像里没装 psql，但 Flyway 的 validateOnMigrate=true 会尝试调用它校验 SQL 语法；或者 jOOQ 的生成任务连的是内存 H2 库，而 Flyway 迁移脚本里用了 PostgreSQL 特有语法（如 ON CONFLICT DO NOTHING），导致生成阶段就抛 org.h2.jdbc.JdbcSQLException。
立即学习“Java免费学习笔记（深入）”；
- CI 的
build阶段统一用真实数据库容器（如postgres:15），而不是 H2 ——jOOQ生成必须和运行时方言一致 -
Flyway配置中关闭validateOnMigrate（开发可开，CI 应关），改用flyway info检查迁移状态是否 clean -
jOOQ的generator插件必须声明jdbc依赖（如postgresql），否则生成时连不上 PG，报java.lang.ClassNotFoundException: org.postgresql.Driver
真正麻烦的从来不是配置项本身，而是 Flyway 的迁移状态、数据库实际结构、jOOQ 生成时连接的库三者之间是否严格同步——少一次 flyway clean 或多一个未提交的 SQL 文件，类型安全就断在生成那一刻。
