dockerfile 无法实现容器内进程自动重启，真正的自愈依赖运行时重启策略与健康检查组合；dockerfile 仅能通过 healthcheck 指令定义服务可用性检测，为重启提供判断依据。
Dockerfile 本身不能直接实现“容器内进程崩溃后的自动重启”，因为 Docker 的设计原则是每个容器只运行一个主进程（PID 1），而该进程退出即导致容器停止——Docker 不会在容器内部重启应用进程。真正的自动恢复，靠的是 容器级重启策略 + 健康检查 的组合，且必须在镜像构建之外（运行时或编排层）配置。Dockerfile 只能为这一机制打下基础。
在 Dockerfile 中定义健康检查（关键一步）
健康检查让 Docker 能识别“假活”：端口开着但服务已无响应。它不重启容器，但为后续触发重启提供判断依据。
- 使用
HEALTHCHECK指令，推荐放在 Dockerfile 末尾 - 指定检测频率、超时、重试次数和启动宽限期，避免过早误判
- 检测命令应真实反映服务可用性，例如对 PHP 应用可检查健康接口或关键文件
示例（适用于 Web 服务）：
HEALTHCHECK --interval=30s --timeout=5s --start-period=40s --retries=3 \ CMD curl -f http://localhost:80/health || exit 1
注意：start-period 给应用留出初始化时间；retries 连续失败后容器状态变为 unhealthy，但此时仍需配合 restart 策略才能真正重启。
不建议在 Dockerfile 中启动 supervisord 或循环脚本
用 shell 循环（如 while true; do php-fpm; done）或进程管理器（如 supervisord）来“重启内部进程”，违背了 Docker 的单进程理念，会带来问题：
- PID 1 不再是应用进程，信号（如 SIGTERM）无法正确传递，导致
docker stop超时或强制 kill - 日志混杂、退出码失真，Docker 无法准确判断容器是否真正失败
- 掩盖真实故障，让问题更难定位
这类做法属于“绕过 Docker 机制”，不是自愈，而是掩盖——应优先优化应用健壮性，而非在容器里做进程兜底。
真正起效的重启行为必须在运行时配置
Dockerfile 是静态构建产物，而重启策略（restart policy）是容器实例的运行时属性，只能通过以下方式设置：
-
docker run --restart unless-stopped ...（启动时指定） -
docker update --restart on-failure:3 <container></container>（已有容器补设，需先 stop） - 在
docker-compose.yml中写restart: unless-stopped和healthcheck:块
例如，一个健壮的 PHP 容器部署，Dockerfile 提供健康检查能力，而 docker-compose.yml 决定何时重启：
services:
app:
image: my-php-app:latest
restart: unless-stopped
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost/health"]
interval: 30s
timeout: 5s
retries: 3
start_period: 60s
补充：确保 Docker 守护进程开机自启
即使配置了 unless-stopped 或 always，若宿主机重启后 Docker 服务没起来，容器也不会自动拉起。需确认：
- Linux 系统上执行
sudo systemctl enable docker - 验证
systemctl is-enabled docker返回enabled - 该步骤虽不在 Dockerfile 中，却是整个自愈链路的最后一环
