首要原因是应用未输出到stdout/stderr：docker logs仅捕获标准流，若日志写入文件（如/var/log/app.log）则不可见；其次检查日志驱动是否为none；最后确认主进程是否前台运行。
docker logs 看不到日志，不是 Docker Desktop 坏了，而是应用根本没往 stdout/stderr 写。 容器日志为空的首要原因永远是输出路径错位，不是命令不会用、也不是日志驱动被禁——先确认应用是否真的在向控制台输出内容。
应用日志是否写到了 stdout/stderr？
docker logs 只能捕获容器主进程的标准输出和标准错误流。如果应用把日志写进 /var/log/app.log 或 ./logs/error.log 这类文件，docker logs 就完全看不到。
- 进入容器验证：
docker exec -it，然后运行/bin/sh ps aux | grep -v grep确认主进程 PID，再用ls -l /proc/查看 stdout（fd 1）和 stderr（fd 2）是否连向/fd/{1,2} pipe:或socket:（正常），还是指向某个file:（说明被重定向到文件） - 检查应用配置：比如 Spring Boot 默认用 logback，需确认
logback-spring.xml中有fs.writeFileSync，改用console.log或process.stdout.write - 临时加调试输出：在启动脚本开头插入
echo "[DEBUG] container started at $(date)" >&1，再执行docker logs看这行是否出现——能出现就证明 stdout 是通的，问题出在应用自身日志逻辑
docker inspect 显示日志驱动为 none 怎么办？
如果 docker inspect --format='{{.HostConfig.LogConfig.Type}}' 返回 none，说明该容器启动时显式禁用了日志捕获，docker logs 必然为空。
- 这不是 Docker Desktop 的默认行为，而是启动时加了
--log-driver=none或 Compose 文件里写了logging: { driver: "none" } - 修复方法：删掉容器重建，启动时明确指定
--log-driver=json-file；若用 Compose，删掉logging配置块或改成driver: "json-file" - 注意：修改
/etc/docker/daemon.json不会影响已创建容器的日志驱动，只对新容器生效
容器进程是否前台运行？
Docker 依赖主进程阻塞在前台才能持续采集日志。如果主进程 fork 后退出（变成 daemon 模式），Docker 会认为容器已终止，后续日志就不再捕获。
- 典型错误写法：
CMD ["nginx", "-g", "daemon off;"]是对的，但CMD ["nginx", "&"]或ENTRYPOINT ["sh", "-c", "nginx & wait"]里漏了wait就会导致前台进程立即退出 - 验证方式：
docker ps -a看容器状态是否为Exited (0)或反复重启；docker inspect查看| grep -i 'running\|status' State.Status和State.FinishedAt - Java 应用常见坑：Spring Boot 打包成 jar 后直接
java -jar app.jar &启动，必须去掉&，或用exec java -jar app.jar替代，确保 PID 1 是 Java 进程本身
真正卡住排查的，往往不是“怎么查日志”，而是分不清“日志没产生”“日志没输出到 stdout”“日志驱动被关”“进程没活过 1 秒”这四层。每次遇到空日志，按这三步顺序查：先看应用是否真打了 stdout，再看容器日志驱动是不是 none，最后确认进程有没有在前台卡住——跳过任意一层，都会陷入无效重启循环。
