docker start仅启动已停止容器，不改变运行中容器状态；docker restart则无论容器当前状态如何，均先stop再start，确保配置更新生效。
start 和 restart 是控制容器运行状态最常用的两个命令，它们作用不同、触发时机不同，选错容易导致服务异常或配置未生效。
docker start：只对已停止的容器有效
它不会重启正在运行的容器，也不会重建环境。适用于维护后恢复、测试中断续跑、或批量唤醒一批停用容器。
- 启动单个容器：直接用容器名或 ID，比如 docker start nginx-proxy
- 启动多个容器：一次传多个名字或 ID，如 docker start db redis cache
- 启动所有已停止容器：配合 docker ps -a -q 使用，命令为 docker start $(docker ps -a -q)（注意：这会启动所有非运行态容器，含已退出的）
- 附加到前台运行（-a）或交互模式（-i）：适合调试，但生产环境慎用，例如 docker start -a my-app
docker restart：强制刷新当前状态
无论容器当前是运行中还是已停止，执行 restart 都会先 stop 再 start。这个“先停后启”的过程会重载容器启动时的配置（如挂载卷、端口映射、环境变量），但不会重新拉取镜像或重建容器结构。
- 重启单个容器：docker restart app-server
- 重启多个容器：docker restart web api worker
- 设置超时时间（-t）：避免主进程僵死，比如 docker restart -t 30 app-server 表示最多等 30 秒再发 SIGKILL
- 常用于配置更新后生效：比如修改了 docker run 时的 -e 或 -v 参数，重新创建容器成本高，用 restart 可快速让新挂载或环境变量生效（前提是容器支持热重载或启动脚本读取了这些参数）
什么时候该用 start，什么时候该用 restart？
关键看你想保留还是丢弃当前运行上下文。
- 容器只是暂停/手动 stop 过，没改任何配置 → 用 start 最快最轻量
- 刚更新了宿主机上的配置文件（比如挂载的 config.yaml）、调整了环境变量、或怀疑进程卡住 → 用 restart 确保干净重启
- 想验证容器能否从停止态可靠恢复 → 先 stop，再 start，而不是直接 restart
- CI/CD 流水线中自动部署后需要刷新服务 → 推荐 restart，语义明确且行为可预期
注意 stop 和 kill 的区别对 restart 的影响
restart 内部调用的是 stop（默认 10 秒超时 + SIGTERM），不是 kill。如果容器主进程不响应 SIGTERM，restart 也会等超时后强制终止——这意味着你看到的“重启失败”，往往是因为应用没正确处理退出信号，而非命令本身问题。
- 检查容器是否真停了：docker ps -a | grep your-container，确认 STATUS 是 Exited 而非 Up
- 查看停止原因：docker logs --since "5m" your-container，重点找 panic、timeout 或 signal 相关日志
- 若频繁 restart 失败，建议在 Dockerfile 中定义 STOPSIGNAL SIGQUIT 或调整应用的 shutdown handler
