Docker Compose 应用自主修复需闭环整合健康探测、状态响应、资源约束和启动依赖：HTTP业务探针、合理start_period/retries、严格退出码；按服务特性选restart策略；depends_on须用service_healthy；配mem_limit/cpus及JVM容器感知；主进程须优雅处理SIGTERM。
要让 Docker Compose 编排的应用真正具备自主修复能力，不能只靠“重启”应付了事——得把健康探测、状态响应、资源约束和启动依赖四者串成闭环。关键不是容器挂了再拉起来，而是提前识别异常、精准触发恢复、避免连锁失败。
健康检查必须真实有效
健康检查不是摆设，得反映应用真实就绪状态：
- 用 HTTP 探针调用 /health 或 /actuator/health 这类业务级接口，别只用
nc -z localhost 8080检端口——端口通不代表服务可用 - start_period 至少设为应用冷启动时间的 1.5 倍：Spring Boot 默认需 60–90 秒，GitLab 建议 300 秒；否则容器还没起来就被标记 unhealthy
- retries 设为 3，interval 控制在 20–30 秒之间：太敏感易误判，太迟钝会延长故障窗口
- 退出码必须严格：0=健康，非0=不健康；curl -f 天然满足，避免用 bash 脚本返回模糊值
重启策略要匹配服务特性
不同服务该用哪种 restart 策略，直接决定自愈是否可靠：
-
长期运行的核心服务（如 API、GitLab、MinIO）用
restart: unless-stopped：既防宿主机重启后服务离线，又允许运维主动停机维护 -
有状态或易偶发失败的服务（如数据库客户端、消息消费者）选
restart: on-failure:5：只在崩溃时重试，避免健康但短暂超时的服务陷入无限重启 -
绝对不要对 OOM 高风险服务用
always：内存泄漏被 kill 后立即重启，只会反复触发 OOM Killer，拖垮整台机器
依赖启动必须等真正就绪
depends_on 默认只等容器启动完成，不等服务就绪——这常导致上游因下游未 ready 而报错退出：
-
用
condition: service_healthy替代service_started：确保依赖服务通过自身 healthcheck 后才启动当前服务 - 例如 PostgreSQL 服务需配合 pg_isready 健康检查：
test: ["CMD-SHELL", "pg_isready -U postgres"] - 若依赖服务无原生健康端点，可在启动脚本中加等待逻辑，比如
until curl -f http://redis:6379/ping; do sleep 2; done
资源限制与优雅终止缺一不可
很多“崩溃”本质是失控，而非代码缺陷：
-
运行时强制加
mem_limit和cpus：如deploy: resources: limits: memory: 1g; cpus: '1.0'，防止单容器吃光资源 -
JVM 应用必须启用容器感知：加
-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0，否则 JVM 无视 mem_limit 导致 OOM - 主进程必须处理 SIGTERM：收到后停止新请求、清空队列、关闭连接池，再 exit 0；Nginx、Redis 官方镜像已内置，自研服务需主动实现
