Java应用需通过docker-compose.yml的healthcheck与service_healthy条件确保MySQL就绪，并在应用层配置连接池重试和初始化容错机制，必要时用wait-for-it.sh做TCP端口级兜底。
Java 应用本身不直接控制 Docker 容器启动顺序，真正起作用的是 docker-compose.yml 中的配置。关键不是 Java 代码写什么，而是如何让 Java 服务（比如 Spring Boot）**等到 MySQL 真正可连接后才开始初始化数据库操作**——这需要 Compose 层和应用层协同配合。
depends_on 只控制容器启动，不保证 MySQL 就绪
很多人误以为只要写：
web:
build: .
depends_on:
- mysql
mysql:
image: mysql:8.0
就能让 Java 应用连上 MySQL。但事实是：depends_on 仅确保 mysql 容器进程已启动（docker ps 显示 Up），而 MySQL 实际可能还在初始化数据目录、加载插件、监听端口——此时 Spring Boot 的 JDBC URL 连接会立刻失败，报 Connection refused 或 Communications link failure。
必须搭配 healthcheck + condition: service_healthy
这才是让依赖“真正生效”的标准做法：
立即学习“Java免费学习笔记（深入）”；
- 为
mysql服务添加健康检查，用mysqladmin ping验证服务层可用性：
mysql:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: rootpass
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-prootpass"]
interval: 10s
timeout: 5s
retries: 10
start_period: 40s
- 在 Java 服务（如
web）中，把depends_on改为带条件的形式：
web:
build: .
depends_on:
mysql:
condition: service_healthy
这样 Compose 会轮询 MySQL 的健康状态，直到连续 10 次通过检查，才启动 Java 容器——此时 MySQL 已监听 3306 并接受连接请求。
Java 应用自身也要做容错，不能只靠 Compose
即使 Compose 等到了 MySQL 健康，网络抖动、事务锁、主从延迟等仍可能导致首次连接失败。Spring Boot 应主动重试：
- 启用 HikariCP 连接池的连接测试与重试机制（
spring.datasource.hikari.connection-test-query=SELECT 1） - 配置初始化失败时自动重试（Spring Boot 3.2+ 支持
spring.sql.init.continue-on-error=true） - 或使用
@EventListener(ApplicationReadyEvent.class)手动校验 DataSource 可用性，失败则延迟重试
复杂场景用 wait-for-it.sh 做兜底
若 MySQL 是第三方镜像、无法自定义 healthcheck，或需验证特定库/表是否存在，可在 Java 容器启动前插入等待脚本：
- 下载脚本并挂载进容器：
curl -o wait-for-it.sh https://raw.githubusercontent.com/vishnubob/wait-for-it/master/wait-for-it.sh - 修改 Java 服务的
command：
command: ["sh", "./wait-for-it.sh", "mysql:3306", "--timeout=60", "--", "java", "-jar", "app.jar"]
注意：wait-for-it.sh 只检测 TCP 端口通不通，不执行 SQL 查询；它适合快速验证端口可达性，但不能替代 healthcheck 的协议级判断。
