DockerStart 不是真实命令，正确方法是设置容器重启策略（如--restart unless-stopped）并启用 Docker 守护进程开机自启；还需检查网络、依赖、端口及应用绑定地址等常见问题。
dockerstart 并不是一个真实存在的 docker 命令或内置工具，它不是解决宿主机重启后容器掉线的正确方法。真正起作用的是 容器的重启策略（restart policy） 和 docker 服务本身的开机自启配置。
宿主机重启后，所有容器默认处于停止状态，除非你提前为它们设置了合适的重启策略，并确保 Docker 守护进程能随系统自动启动。
✅ 正确做法：用 --restart 策略让容器“自己回来”
创建容器时，必须显式指定 --restart 参数：
--restart always
容器无论因何退出（包括被 kill、崩溃、宿主机重启），都会自动重启。--restart unless-stopped（推荐用于生产）
行为同always，但如果你手动执行过docker stop，它就不会再自动拉起——更可控，避免误启。
示例：
docker run -d \ --restart unless-stopped \ --name myapp \ -p 3000:3000 \ myapp-image
⚠️ 注意：这个策略只能在
docker run创建时设置，或用docker update后续补上。docker start本身不接受--restart，也无法给已运行容器添加该行为。
如果容器已存在但没设策略，立刻补上：
docker update --restart unless-stopped myapp
✅ 确保 Docker 守护进程开机自启
即使容器设了 unless-stopped，若 Docker 服务没起来，一切归零。
检查并启用：
sudo systemctl enable docker sudo systemctl is-enabled docker # 应返回 enabled
验证重启后 Docker 是否正常运行：
systemctl status docker # 看是否 active (running)
✅ 宿主机重启后容器仍连不上？别只盯容器，查网络和依赖
常见“看似启动成功，实则无法访问”的原因：
自定义 bridge 网络丢失（Docker 默认不持久化网络）
→ 需配合脚本重建网络 + 重新连接容器，或启用live-restore（见/etc/docker/daemon.json）容器启动太快，依赖的服务（如数据库、Redis）还没就绪
→ 加健康检查 + 启动等待逻辑（如用wait-for-it.sh或docker compose的depends_on+ healthcheck）端口被占用、挂载目录不存在、SELinux/权限拦截
→ 查日志定位：docker logs myapp或journalctl -u docker -n 50容器内应用自身未监听正确地址（如只监听
127.0.0.1）
→ 检查应用配置，确保绑定0.0.0.0
❌ 不要做的：写脚本轮询 docker start
有人写 systemd service 或 crontab 定期执行 docker start xxx，这是反模式：
- 容器可能刚启动又失败，脚本反复触发造成状态混乱
- 绕过 Docker 的重启重试机制（比如
on-failure的重试次数控制） - 健康检查、依赖管理、优雅关闭等功能全部失效
正确路径始终是：
建容器时配好 --restart + 开机自启 dockerd + 必要时加固网络与依赖
不复杂但容易忽略。
