Docker 日志排查时，先把 follow、tail、since 这几个选项用顺手

本地容器一旦启动失败或者接口突然异常，很多人的第一反应都是先 docker exec 进去看看，或者直接把容器删掉重启。这样做当然有时候也能解决问题，但从排查效率看，并不总是最优。很多容器问题，其实靠 docker logs 就能先把大方向判断出来，尤其是把 follow、tail、since 这些选项用顺手以后，定位速度会快不少。

不要一上来就看全部日志

容器运行一段时间后，日志往往已经很长了。直接把全部日志打一遍，既浪费时间，也容易被历史信息干扰。更实用的方式是先看最近几十行，确认当前错误是不是刚发生、是否重复出现、有没有明显的启动失败信息。

tail 的意义就在这里。它不只是“少看一点”，而是帮助你把注意力先放在最近一次状态变化上。

follow 适合观察“现在正在发生什么”

当你刚改完配置、准备重新请求一次接口，或者等某个任务执行结果时，follow 非常好用。它让日志像实时流一样持续输出，你不需要反复敲命令刷新。

本地开发里最常见的两个场景就是：一边看 API 容器日志，一边从浏览器或 Postman 发请求；或者一边观察消费者容器日志，一边手动往队列里塞一条消息。这个时候实时追踪会比事后翻全量日志高效得多。

since 能帮你把“重启前后”切开

排查容器时最怕的不是没日志，而是日志太多、时间跨度太大。你刚重启了容器，却还混着半小时前的异常信息，很容易误判问题还在继续。since 的价值就是帮你把时间范围切干净，只关注某个时间点之后的输出。

这在排查“我刚修改完环境变量到底有没有生效”这种问题时特别有帮助。你能更明确地区分出旧问题和新问题。

日志先看趋势，再看细节

我比较常用的排查顺序是：

• 先 tail 最近日志，看是不是启动阶段就报错
• 再配合 follow 重现一次操作，观察实时输出
• 如果中途重启过，再用 since 把时间范围缩小

这样做的好处是不会一开始就被海量日志压住，也能更快看出问题是在启动、请求处理还是后台任务阶段出现的。

日志命令用顺手，本地联调会省很多时间

容器时代的排查习惯，和以前直接看宿主机进程日志还是有些不同。你不一定需要立刻进入容器内部，也不一定需要先重启。先把 docker logs 的这几个选项掌握好，很多本地问题都能更快缩小范围。

排查效率往往不是来自更复杂的命令，而是来自你是否愿意先用最直接的观测手段把问题看清楚。