spring boot 启动时数据库未就绪会导致连接失败，属时序问题；可通过配置 hikaricp 重试、延迟 datasource 初始化、禁用启动建表、容器化等待等手段解决。
spring boot 默认启动时会尝试初始化所有 bean，包括数据库连接池。如果数据库服务（如 mysql）还没就绪，而应用已开始建立连接，就会报类似 communications link failure 或 connection refused 的错——这不是代码写错了，而是“后端抢在数据库前面启动”导致的时序问题。
让应用等 DB 就绪再连
Spring Boot 本身不内置“等待数据库启动”的机制，但可通过以下方式控制依赖顺序和重试逻辑：
-
启用连接池健康检查与重试：在
application.yml中配置 HikariCP 的重试参数，让它自动多试几次，而非启动即失败：
-
延迟 DataSource 初始化：用
@Lazy注解延迟数据源相关 Bean 的创建，或通过@DependsOn显式声明依赖关系（慎用，仅适用于自定义初始化逻辑）； - 引入 Spring Boot Actuator + 自定义 Health Indicator：配合外部脚本或 Kubernetes 的 readiness probe，先确认 DB 可连通再对外提供服务；
-
容器化部署时加启动等待：Docker Compose 中用
depends_on+ 自定义 healthcheck，或用wait-for-it.sh脚本确保 MySQL 容器 ready 后再启动应用。
避免启动阶段强制建连
有些场景（比如 JPA 启动时执行 DDL）会强制触发连接。若你不需要启动时建表或校验，可关闭：
- 禁用 Hibernate 启动时的 schema 验证：
spring.jpa.hibernate.ddl-auto=none； - 关闭 Flyway/Liquibase 的自动迁移（如有）：
spring.flyway.enabled=false； - 移除
@PostConstruct或CommandLineRunner中对数据库的早期调用。
开发/测试环境快速兜底
本地调试时不想反复启停 MySQL，可临时跳过数据源自动配置：
- 启动类上排除：
@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)； - 或配 profile 忽略：
spring.profiles.active=dev，并在application-dev.yml中不配spring.datasource。
核心思路不是“强行让后端变慢”，而是“别在启动瞬间强依赖 DB 可用”。合理配置连接池行为 + 控制初始化时机，就能稳住启动流程。
