首先，咱们先把容器日志的核心逻辑讲清楚，再解答你遇到的具体问题：

容器日志的基本工作原理 #

Docker（以及大部分容器运行时）的日志驱动，默认行为是捕获容器内主进程的stdout和stderr输出流。以Docker默认的json-file日志驱动为例：

• 当容器启动后，日志驱动会持续监听主进程的标准输出和标准错误流；
• 这些输出会被驱动收集、格式化（比如加上时间戳）后存储到宿主机的指定位置（默认是/var/lib/docker/containers/<容器ID>/<容器ID>-json.log）；
• 你执行docker container logs <容器名>时，本质就是从这个存储文件里读取并展示内容。

这也是为什么最佳实践推荐把应用日志直接输出到stdout/stderr：不需要额外维护日志文件，日志驱动直接捕获，后续也更容易对接集中日志系统（比如ELK、Loki），还能避免容器内日志文件占满磁盘的问题。

为什么tail -f /var/log/container.log的输出能被docker logs捕获？ #

你观察到的这个现象，核心逻辑其实很简单：

• tail -f这个命令的作用，是持续读取目标日志文件的新增内容，并把这些内容输出到它自己的stdout；
• 如果这个tail命令是容器的主进程（也就是Dockerfile里CMD/ENTRYPOINT指定的启动命令），那么Docker日志驱动就会像监听普通应用的stdout一样，捕获这个tail进程的输出——这就是你用docker logs能看到container.log内容的原因。

举个具体的例子：如果你的Dockerfile最后一行是：

CMD ["tail", "-f", "/var/log/container.log"]

容器启动后，主进程就是tail，它会不断把container.log的新内容打印到自己的stdout，而Docker日志驱动一直在监听这个主进程的输出流，自然就把这些内容收集起来了。

注意：如果tail是容器内额外启动的子进程（不是主进程），那Docker日志驱动是不会捕获它的输出的——只有主进程的stdout/stderr才会被默认日志驱动处理。

这种做法的潜在问题 #

虽然这种方式能让docker logs看到内容，但它并不符合最佳实践，主要有这些隐患：

• 多了一层tail进程，额外消耗容器内的CPU和内存资源；
• 如果你的应用进程崩溃了，但tail进程还在运行，容器会被标记为“正常运行”，你无法及时发现应用故障；
• 容器内的container.log文件会持续占用存储空间，如果没有配置日志轮转，很容易撑满容器的磁盘配额；
• 相比直接输出到stdout/stderr，这种方式的日志后续更难对接集中日志系统，需要额外的配置来收集文件日志。

内容的提问来源于stack exchange，提问作者Ivan Hernandez