docker容器默认无停止顺序，需通过docker-compose.yml的stop_order（first/last）、健康检查、应用层sigterm监听及init进程（如tini）协同实现优雅终止，生产环境推荐kubernetes prestop钩子与terminationgraceperiodseconds保障。
容器本身没有内置的“停止顺序”机制，docker 默认按任意顺序停止容器。要防止上游服务因下游服务提前退出而调用失败（比如 api 服务还在发请求，数据库容器却已关闭），关键不是靠 docker 自身排序，而是通过外部协调和容器间依赖控制来实现优雅终止。
明确容器依赖关系并启用健康检查
在 docker-compose.yml 中声明服务依赖，并配合健康检查，让上游服务确认下游就绪后再启动——这虽不直接控制停止顺序，但为后续有序终止打下基础：
- 用
depends_on+condition: service_healthy确保启动时依赖满足 - 为数据库、缓存等关键服务配置
healthcheck，例如 Redis 检查redis-cli ping是否返回PONG - 注意：
depends_on不影响docker-compose down的停止顺序，默认仍按启动逆序停（即最后启动的先停），但健康检查能避免“假启动”导致的级联失败
使用 stop_order 和 shutdown 脚本控制终止逻辑
Docker Compose v2.20+ 支持 stop_order 字段（值为 first 或 last），可显式指定停止优先级：
- 将数据库、消息队列等后端服务设为
stop_order: last - 将 API 网关、前端服务等设为
stop_order: first - 需搭配
docker compose down使用，docker stop单个容器时该字段无效
同时，在应用内监听 SIGTERM 信号，收到后主动拒绝新请求、等待处理中请求完成（如 Spring Boot 的 server.shutdown=graceful），再真正退出。
借助 init 系统或进程管理器做终止协调
在容器内运行轻量级 init 进程（如 tini）或使用 supervisord，可更可靠地转发信号并管理子进程生命周期：
- 在
Dockerfile中添加ENTRYPOINT ["tini", "--"]，确保SIGTERM正确传递给主进程 - 若容器内有多个进程（如 Nginx + PHP-FPM），用
supervisord统一收信号，按预设顺序关停子服务 - 避免主进程忽略
SIGTERM导致docker stop超时后强制 kill（SIGKILL），引发连接中断或数据未刷盘
生产环境推荐：结合编排平台的生命周期钩子
单机 Docker Compose 能力有限，真实微服务场景建议迁移到 Kubernetes：
- K8s 的
preStop生命周期钩子可在 Pod 终止前执行命令（如调用服务下线接口、关闭负载均衡注册） - 通过
terminationGracePeriodSeconds控制宽限期，配合 readinessProbe 确保流量已切走再终止 - StatefulSet 对有状态服务（如数据库主从）提供严格终止顺序保障
