docker logs -f --tail 100 是最实用的日志查看组合，可避免卡顿、确保实时性并获取最新上下文；它仅捕获 stdout/stderr，不读取文件日志，需确认应用输出方式及日志驱动配置。
docker logs 是唯一能直接读取容器控制台日志的命令，它只捕获 stdout/stderr，不读文件日志。用错方式或参数，就看不到想看的内容。
为什么 docker logs 有时显示空白或旧日志
常见错误是漏掉 -f 或没指定 --tail，导致只看到容器启动初期的日志（比如 entrypoint 脚本输出），而应用真正运行后的日志还没刷出来。
- 容器刚启动时，应用可能延迟几秒才开始输出业务日志，
docker logs my-app默认显示全部历史，但若应用还没打日志，就看起来“空” - 如果日志量极大（如高频 debug 日志），不加
--tail N会卡住终端甚至 OOM -
docker attach虽然也能看到实时输出，但它会接管 stdin/stdout，退出需 Ctrl+P Ctrl+Q，容易误操作中断容器进程，不推荐用于日志查看
docker logs -f --tail 100 是最实用的组合
这个组合覆盖了 95% 的日常排查场景：既避免刷屏，又确保看到最新上下文，还能持续跟进。
-
--tail 100（或简写-n 100）跳过历史积压，直奔最近 100 行，防止卡顿 -
-f持续监听新日志，效果等同于tail -f，不是“一次性快照” - 加
-t（即--timestamps）可确认日志时间是否对齐系统时钟，避免因容器内时区错乱导致的排查偏差 - 示例：
docker logs -f -t --tail 100 api-server
查不到日志？先确认日志是不是真的从 stdout 出来的
Docker 默认只收集标准输出和标准错误。很多应用（尤其 Java/Node.js）默认把日志写进文件，比如 /var/log/app.log，这时 docker logs 必然为空。
- 先执行
docker inspect api-server --format='{{.HostConfig.LogConfig.Type}}'确认日志驱动是json-file（默认值），排除被配置成none或远程驱动 - 再检查应用是否重定向了输出：进容器运行
docker exec -it api-server ls -l /proc/1/fd/{1,2}，看 fd 1 和 2 是否指向pipe:或socket:，而不是文件路径 - 如果确实是写文件，用
docker exec -it api-server tail -f /var/log/app.log替代
别依赖 docker logs 做长期日志归档
它的底层是 JSON 文件，默认无轮转、无压缩、不限大小。一个高流量服务跑一周，/var/lib/docker/containers/xxx/xxx-json.log 可能突破 10GB。
- 上线前务必加日志限制：
--log-opt max-size=10m --log-opt max-file=3 - 不要手动删
*-json.log文件，Docker daemon 不感知，可能导致docker logs报错或返回空 - 生产环境建议换日志驱动，比如
fluentd或syslog，把日志导出到集中系统
