直接调大healthcheck的timeout和start_period参数，配合应用层重试与依赖就绪等待，可有效防止容器卡在starting状态或被误判不健康而反复重启。
直接调大健康检查的 timeout 和 start_period 参数，再配合应用层重试与依赖就绪等待，就能有效防止容器卡在 starting 状态或被误判为不健康而反复重启。
关键参数必须设对
超时问题本质是健康检查在应用真正就绪前就失败了。Docker Compose 的 healthcheck 中两个参数最关键：
- timeout：单次检查命令执行的最大允许时间。默认常为 5–10 秒，对 Java/Spring Boot 或带数据库初始化的服务明显偏短。建议设为 20–30 秒，留出网络延迟和慢查询缓冲。
-
start_period：容器启动后，健康检查开始前的宽限期。它不是“等待多久才检查”，而是“这期间所有检查失败都不算数”。若服务冷启动需 45 秒，
start_period: 60s才能避免早期误判。
示例配置：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
healthcheck: test: ["CMD-SHELL", "curl -f http://localhost:8080/actuator/health || exit 1"] interval: 30s timeout: 30s retries: 3 start_period: 60s
让依赖服务真正就绪，不止“容器运行”
depends_on 只等容器启动，不等服务可用——这是多数超时问题的根源。比如 PostgreSQL 容器已 running，但 initdb 没完成、端口未监听，你的应用一连就失败，然后健康检查也失败，陷入死循环。
- 在应用启动脚本里加连接重试（如用
wait-for-it.sh或dockerize -wait tcp://db:5432） - 或在 Compose 中为依赖服务显式定义健康检查，并用
condition: service_healthy：
services:
db:
image: postgres:15
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 10s
timeout: 5s
retries: 10
app:
build: .
depends_on:
db:
condition: service_healthy
应用自身也要防阻塞
容器僵死常因主线程卡住，而非健康检查失败。例如 Spring Boot 连接 MySQL 时，默认重试 3 次、每次等 30 秒，总共卡 90 秒才抛异常——此时容器早被判定 unhealthy 并 kill。
- 缩短数据库连接超时：
spring.datasource.hikari.connection-timeout=5000 - 禁用初始化失败阻塞：
spring.datasource.initialization-mode=never（改由 flyway 或外部初始化） - 把非核心依赖（如 Config Server、Redis）设为懒加载或降级兜底，避免启动阶段强依赖
验证是否生效
别只看 docker-compose ps 显示 “healthy” 就以为万事大吉。要确认三点：
- 运行
docker inspect <container> | grep -A 10 Health</container>，核对StartPeriod、Timeout是否与配置一致 - 查日志：
docker-compose logs app | grep health，看首次成功检查发生在启动后第几秒 - 模拟慢依赖：临时把 db 健康检查改成
test: ["CMD-SHELL", "sleep 50 && pg_isready -U postgres"]，观察 app 是否真等到 50 秒后才开始检查
