docker compose不感知异常类型，仅依据容器主进程退出码和restart策略决定是否重启：always无条件重启，unless-stopped排除手动停止，on-failure仅非零退出码重启（可限次），no不重启；需配合healthcheck识别假活，并通过logs和inspect查退出码（如137为oom）定位根因。

Docker Compose 本身不直接监控或干预容器内部的异常中断（比如应用 panic、段错误、空指针崩溃等），它依赖 Docker 引擎提供的 重启策略（restart policy） 来响应容器进程退出这一结果。换句话说，Compose 不“感知”异常类型，只关心容器主进程是否退出，以及退出码是否符合预设条件。

重启策略决定是否拉起新实例

当容器内应用崩溃导致主进程退出时，Docker 守护进程会捕获退出状态，并根据你配置的 restart 字段决定是否重启容器：

• always：不管退出码是 0 还是非 0，立即重启——适合必须常驻的服务，如 Nginx、Redis
• unless-stopped：同 always，但若你手动执行过 docker stop，则不再自动拉起——生产环境最常用
• on-failure[:max]：仅当退出码非 0 时重启，可限制最多重试次数（如 on-failure:3）——避免无限崩溃重启循环
• no：默认行为，退出后不重启——适用于调试、一次性任务

需要配合健康检查提升判断精度

单纯靠进程退出码有局限：有些应用进程没死，但已卡死或无法响应请求（例如死锁、内存泄漏后假活）。这时单靠 restart 策略无法触发恢复。建议在 Compose 中启用 healthcheck：

Docker Image Puller

使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。

下载

• 定义周期性探测（如 curl -f http://localhost/health || exit 1）
• 设置超时、重试间隔和失败阈值
• 当健康检查连续失败达到阈值，Docker 会将容器状态标记为 unhealthy
• 注意：健康状态本身不会触发重启，但可配合外部工具（如 watchtower、自定义脚本）或上层编排系统（如 Swarm、K8s）做进一步动作

日志与退出码是排查关键线索

容器异常中断后，第一时间应查看日志确认根本原因：

• docker compose logs -f <service></service> 实时跟踪输出
• docker compose ps 查看当前状态和退出码（Exit Code 列）
• 退出码为非 0（如 137 表示 OOM Kill，139 表示 Segmentation Fault）能快速定位问题类型
• 结合 docker inspect <container></container> 查看 State.FinishedAt 和 State.ExitCode

避免掩盖问题的配置陷阱

盲目使用 restart: always 可能让故障“静默持续”：

• 应用反复崩溃又重启，日志被轮转覆盖，难以追溯首次异常
• 资源类问题（如内存溢出）可能引发雪崩，重启反而加剧压力
• 建议搭配资源限制（deploy.resources.limits）和监控告警，而非仅依赖自动重启