Exited状态表示容器主进程（PID 1）已终止，生命周期结束；根本原因是PID 1退出，常见于CMD/ENTRYPOINT命令执行完即退、镜像缺失shell、WSL2挂载权限异常、防火墙拦截或段错误等，须通过docker logs和inspect查退出码与stderr定位。
Exited 状态表示容器的主进程（PID 1）已经终止，容器生命周期结束。这不是卡死、也不是暂停，而是 Docker 明确认定“任务已完成或失败”，于是收走资源、停在那儿等你处理。
为什么 Docker Desktop 上容器一启动就 Exited
根本原因永远是：PID 1 进程退出了。Docker Desktop 和 Linux CLI 行为一致，只是 GUI 界面可能掩盖了命令行里的关键线索。常见诱因包括：
-
CMD或ENTRYPOINT指向一个执行完就退出的命令（比如echo "ok"、ls /app），不是长期运行的服务 - 镜像里没装 shell，但你在
docker run里写了/bin/sh -c "xxx"—— 直接报Exit Code 127 - Docker Desktop 启用 WSL2 后，某些挂载路径权限异常（如 Windows 路径映射到
/mnt/wsl/...），导致程序 open 失败退出 - Windows 防火墙或杀软拦截容器网络初始化，应用因连接超时主动退出（日志里常有
connect: connection refused或timeout）
docker logs 看不到输出？说明进程根本没活到打日志
这是 Docker Desktop 用户最常误判的一点：界面里点“Logs”显示空白，就以为“没错误”。其实更可能是进程启动失败早于任何 stdout 输出，比如：
-
Exit Code 126：命令存在但不可执行（脚本没+x，或二进制架构不匹配） -
Exit Code 139：程序启动瞬间段错误（SIGSEGV），连日志模块都没加载成功 - 使用
scratch镜像且未正确打包二进制，docker run报"executable file not found"但 GUI 不显示 stderr
务必切到 Terminal，手动执行：docker logs <container_id> + docker inspect <container_id> --format='{{.State.ExitCode}}'，别信 GUI 的“Log”标签页。
重启策略在 Docker Desktop 里容易被忽略的边界
--restart=always 或 restart: "always" 看似能兜底，但在 Desktop 场景下有硬限制：
- 如果退出码是
0（比如 cron 任务正常完成），Docker 不会重启——它认为“任务成功”，这是设计行为，不是 bug - WSL2 底层资源不足时（尤其内存默认只分 1GB），容器反复
Exit Code 137，但重启策略照常触发，结果是快速循环创建又 OOM 杀死，磁盘和 inode 被耗尽 - Docker Desktop 自带的 Kubernetes（minikube 替代品）启用后，部分容器受 k8s 控制器接管，
docker start可能被覆盖或拒绝
真正要盯住的，永远是退出码和第一行 stderr —— 它们不会说谎，也不会被 GUI 截断。Docker Desktop 是工具，不是黑箱，它的退出逻辑和服务器上完全一致，只是调试路径多了一层 WSL2 和 Windows 集成层。
