静态块不适合做Schema同步，因其在类加载时运行，此时Spring容器未启动、无事务上下文、无错误重试与环境感知能力；应采用Flyway/Liquibase等专业工具在应用启动早期可控执行。
静态块（static block）本身不能直接实现数据库 Schema 的自动同步。它只是 Java 类加载时执行的一段初始化代码，不具备连接数据库、读取元数据、比对结构或执行 DDL 的能力。把“Schema 同步”交给 static 块，属于职责错位，也违背了分层设计原则。
为什么静态块不适合做 Schema 同步
静态块在类首次被加载时运行，此时：
- Spring 容器可能尚未启动，DataSource、JdbcTemplate 等基础设施不可用
- 没有事务管理上下文，无法安全执行建表/改表操作
- 缺乏错误重试、版本校验、回滚机制，失败即中断应用启动
- 无法感知环境差异（dev/test/prod），容易在生产环境误执行 DDL
真正可行的启动期 Schema 同步方式
企业级项目中，Schema 同步应在应用生命周期的**可控阶段**完成，主流方案如下：
- Flyway / Liquibase 初始化：在 Spring Boot 启动早期，由这些工具自动扫描 classpath 下的 migration 脚本（V1__init.sql、V2__add_user_status.sql），连接数据库并按序执行。支持校验 checksum、记录 schema_version 表、支持 undo
- Spring Boot + JPA Hibernate ddl-auto=validate/update（仅限开发）：通过 spring.jpa.hibernate.ddl-auto=validate 可校验实体与表结构是否一致（报错但不修改）；update 可自动加字段（不删字段、不改类型），但生产禁用
- Qoder @database 上下文注入（开发提效）：在 JetBrains IDE 中，通过 @database 将真实 Schema 注入 AI 编程上下文，辅助生成合规 SQL 或评审变更，属于开发侧辅助，不参与运行时同步
如果非要“在启动时触发”，推荐轻量封装方式
可定义一个 @PostConstruct 方法或实现 ApplicationRunner，在 Spring 容器就绪后执行校验逻辑：
- 读取当前数据库 schema（如查询 information_schema.columns）
- 与预置的 JSON Schema 描述文件比对（如 fields.json）
- 发现缺失字段时，记录告警日志或抛出 StartupException，阻断上线流程
- 不自动执行 ALTER，而是推动走标准发布流程（Flyway 脚本 + CI 流水线）
靠 static 块硬编码同步逻辑，既不可测、不可控，也不符合现代数据库治理规范。重点应放在工具链标准化和流程自动化上，而不是在类加载阶段“抢跑”。
