docker容器自愈能力需一体化设计，核心是healthcheck（如curl -f /health || exit 1）与重启策略（如--restart=on-failure:5）闭环联动，配合进程守护、资源限制和优雅终止机制。
要让容器应用系统具备自愈能力，关键不是等出问题再补救，而是从镜像构建、进程管理、资源约束到运行时策略做一体化设计。核心在于“感知异常”和“自动响应”两个环节必须闭环，缺一不可。
在Dockerfile中嵌入健康检查逻辑
HEALTHCHECK 是容器自我诊断的起点。它不是可选项，而是自愈系统的“感官神经”。必须在构建阶段就写进镜像，而不是运行时临时加：
- 用 CMD curl -f http://localhost:8080/actuator/health || exit 1 这类真实探活命令，避免只检查端口通不通
- 合理设置 --start-period=15s，给 Spring Boot 或 Node.js 等应用留足初始化时间，防止启动慢被误杀
- --retries=3 是平衡灵敏度与稳定性的关键：太少易误判，太多会延迟恢复
- 退出码必须严格：0=healthy，1=unhealthy；2 不可用，不要用
选用或构建支持进程自愈的基础环境
标准 Alpine 或 Ubuntu 镜像里，主进程一挂整个容器就退出——这不叫自愈，叫单点失效。得让容器内部有“守夜人”：
- 直接基于 phusion/baseimage-docker 构建，它自带 my_init 和 Runit，只要把启动脚本放 /etc/service/myapp/run，崩溃后秒级拉起
- 或者集成 s6-overlay，通过 /etc/s6-overlay/s6-rc.d/ 定义服务依赖与重启条件，适合多进程协作场景
- 不推荐在容器里跑 supervisord + bash 脚本组合，维护成本高且信号转发容易出错
限制资源并确保优雅终止
很多“崩溃”本质是 OOM 被 kernel 杀掉，或 SIGTERM 未处理导致强制 kill，状态残留引发连锁故障：
- 构建或运行时加 --memory=512m --cpus=1.0，防止一个容器拖垮整台宿主机
- Java 应用必须加 JVM 参数 -XX:+UseContainerSupport，否则无法识别容器内存限制，照样 OOM
- 主进程要监听 SIGTERM：收到后停止接收新请求、完成正在处理的任务、释放连接池，再 exit 0
- Nginx、Redis 等官方镜像默认支持优雅终止，自研服务需主动实现
运行时必须配对启用重启策略
HEALTHCHECK 只负责“说它病了”，真正“打针吃药”靠 restart policy。两者不绑定，自愈就是空谈：
- 生产长期服务用 --restart=unless-stopped：既保证 Docker daemon 重启后自动恢复，又允许运维手动停机维护
- 若配合 HEALTHCHECK，优先选 --restart=on-failure:5：只在 unhealthy 或非零退出时重启，避免健康但偶发失败的服务陷入死循环
- 绝对不用 --restart=always 单独搭配健康检查——一旦应用本身有缺陷（如配置错误导致反复启动失败），就会无限重启，掩盖真实问题
- Docker Compose 中对应字段是 restart: unless-stopped 和 healthcheck: 块，必须同时存在
