容器处于 Exited 状态但 docker logs 为空，主因是日志未产生或被禁用：需先检查 LogConfig.Type 是否为 "none"；再验证 ExitCode（如127表示命令未找到）；若应用写文件日志（如 Nginx），则需用 docker cp 提取对应日志文件分析。
容器处于 exited 状态但
输出为空，不是日志丢失，而是日志根本没产生或被禁用——关键要分清“没日志”和“看不到日志”是两回事。
确认日志是否真实存在
执行
为空时，先验证容器是否真的输出过内容：
运行
，检查
是否存在；若为
，说明启动时加了
，Docker 压根没记录 stdout/stderr
执行
，确认
时间是否合理、
是否非零（如 1、127、137）
若
是 127，常见于命令未找到（如镜像里没有
或
），主进程甚至没来得及执行就失败，自然无日志
排查应用自身是否绕过 stdout 写日志
很多服务（如 Nginx、Java 应用、Supervisor 管理的进程）默认把日志写入文件而非终端。此时
必然为空：
查镜像文档或 Dockerfile，确认日志路径（如
、
）
用
拷出日志文件本地分析
后续优化：构建镜像时重定向应用日志到 stdout（例如 Nginx 加
）
临时进入容器环境复现与诊断
只要容器没被
删除，就能复用其挂载卷、网络配置做深度检查：
Docker Desktop（windows）
当前 Docker 最新稳定版本之一，主要针对稳定性和兼容性进行了修复优化，适合生产环境与日常开发使用。该版本继续强化 AI 开发支持、容器日志管理以及 Docker Engine 的安全能力，对 Windows/macOS/Linux 平台兼容性进行了进一步优化。
下载
用交互方式运行同镜像：
进 shell 后检查：
（配置是否存在）、
（二进制是否缺失）、
（是否被限制内存导致 OOM）
手动执行原 CMD 命令（通过
获取），观察是否报错（如
、
）
预防下次再“静默退出”
避免再次陷入“Exited + 无日志”的被动局面：
启动时加
，防止日志轮转误删
开发阶段优先使用
而非
，第一时间看到终端输出
对关键服务，在入口脚本开头加
，让每条命令执行过程都打印出来
镜像中避免用
这种极简写法，改用
显式捕获错误流
docker logsdocker logs docker inspect | grep -A 5 'LogConfig' "Type": "json-file""none"--log-driver=nonedocker inspect | grep -A 10 'State' FinishedAtExitCodeExitCodeshbashdocker logs/var/log/nginx/error.log/app/logs/app.logdocker cp :/path/to/app.log ./app.log daemon off; error_log /dev/stdout info;rmdocker run -it --volumes-from --network container: --rm sh ls -l /etc/ls -l /usr/bin/cat /proc/self/cgroupdocker inspect --format='{{.Config.Cmd}}' Permission deniedkernel too old--log-opt max-size=10m --log-opt max-file=3docker run -it-dset -xCMD ["app"]CMD ["sh", "-c", "exec app 2>&1"]