健康检查超时主因是docker未在timeout内收到命令响应，需通过docker inspect查health状态、手动执行test命令测耗时，并合理配置--timeout（建议实测最大值1.5–2倍）、--start-period（≥应用就绪时间）、--interval（10s–30s）、--retries（通常3次）。
健康检查脚本执行超时，本质是 docker 在规定时间内没等到命令返回结果。问题不一定是应用挂了，更可能是配置与实际运行节奏不匹配。关键要分清：是脚本本身慢、应用没就绪、还是环境拖慢了执行。
看清楚当前健康检查的实际行为
先别猜，直接查容器真实状态：
- 运行 docker inspect --format='{{json .State.Health}}'，查看完整健康状态快照——重点关注 LastStartTs（上次检查开始时间）、ExitCode（退出码）、Output（输出日志）和 Status（当前状态）
- 如果 Output 为空或只有部分日志，大概率就是被强制终止了，说明超时已发生
- 对比 LastStartTs 和系统当前时间，确认是否真在 timeout 设定范围内没返回
验证健康检查命令能否在容器里“自己跑通”
把健康检查命令复制出来，在容器内手动执行一次：
- 用 docker exec -it sh 进入容器
- 粘贴并运行 healthcheck 的 test 命令（比如 curl -f http://localhost:8080/health 或 mysqladmin ping -h 127.0.0.1 -u root -p'xxx'）
- 观察它实际耗时多少（可用 time 命令包裹）、是否报错、是否依赖外部服务（如数据库还没连上）
- 特别注意：命令中不能含需交互的操作、不能依赖宿主机网络路径、也不能调用被资源限制卡住的进程
核对四个核心参数是否合理
超时不是单看 --timeout，而是它和另外三个参数共同作用的结果：
- --timeout：单次命令最大允许运行时间。若手动测试发现命令平均耗时 4 秒，就别设成 3 秒；建议设为实测最大值的 1.5–2 倍，常见取值 5s–10s
- --start-period：容器启动后“免检宽限期”。Java/Spring Boot 类应用常需 60–120 秒初始化，这个值必须 ≥ 应用真正就绪所需时间
- --interval：两次检查间隔。太短（如 2s）会堆积未完成检查，反而加剧超时；生产建议 10s–30s
- --retries：连续失败几次才判不健康。设为 1 容易误杀，3 是较稳妥起点；若网络抖动多，可临时调到 5
排除环境干扰因素
即使脚本和参数都对，底层环境也可能拖慢执行：
- 检查容器是否设置了过严的 cpu-quota 或 memory limit，导致 curl 或数据库客户端响应变慢
- 确认健康检查目标地址是否正确——比如用 localhost 却监听在 0.0.0.0，或端口映射未生效
- 避免在健康检查中做重操作：查数据库连接、读大文件、发远程 API 调用等。应只检测本地进程存活或轻量 HTTP 端点
- 如果使用 Docker Compose，注意 depends_on + condition: service_healthy 不会等待 start_period 结束，得靠自身 healthcheck 控制节奏
