Linux日志排查利器：tail与head命令的细节、实战与避坑指南

每天和服务器打交道，我见得最多的场景不是写代码，而是“看文件”。看日志、看配置、看数据文件格式，十有八九绕不开两个命令：Linux里的 tail 和 head。很多新手觉得这两个命令简单到不值得学，但实际排查问题的时候，“tail -f 和 tail -F 到底差在哪”“head -n -5 里的负号是干什么的”这种问题，又能问住一批所谓的老手。这篇文章不打算把参数表念一遍，而是从实际使用的角度，把这两个命令的定位、细节、组合用法和我在生产环境踩过的坑一起讲清楚。

1. 为什么不是 cat，而是 tail 和 head

1.1 不是所有文件都适合用 cat 看

很多人刚开始接触 Linux 时，第一种看文件的方式就是 cat，cat 本身没有错，处理小文件、快速确认配置内容时很顺手。但它有一个天然问题：cat 会把整个文件从头到尾都读一遍，然后原样输出到终端。

日志文件在服务器上经常是几十 MB、几百 MB 甚至几个 GB。如果你在 SSH 会话里执行 cat app.log，后果不外乎两种：一是文件内容刷屏到你根本找不到目标内容，二是终端卡死，甚至因为一次性输出太多字符导致 SSH 客户端崩溃。更关键的是，cat 全量读取会产生不必要的磁盘 IO，多台服务器并发读大文件时，可能直接把业务 IO 拉高。

tail 和 head 解决的就是这类“只想看一部分”的需求。head 从文件开头取，tail 从文件末尾取，思路一致，方向相反。它们不会把整个文件塞给你的屏幕，而只取你关心的那部分，处理效率和资源占用都更可控。

1.2 观察“文件两端”是一种高频需求

实际工作中你慢慢会发现，故障信息、错误堆栈、最近写入的记录，绝大多数都出现在文件末尾。日志的特性就是“越新的内容越靠后”，所以排查问题时第一反应总是 tail -n 100 看最后一百行。但有些场景你又需要看文件开头，比如确认 CSV 文件的表头有没有异常、检查配置文件的第一个段落、判断一份导出的数据文件是否有 BOM 头。

把 tail 和 head 放在一起学，一方面是因为它们天然是对称的，参数思维几乎一样；另一方面，它们在管道组合里经常成对出现。学会了对称记忆，你记参数的压力会小很多。

2. tail 的细节里，藏着真正的工作效率

2.1 -n 参数的正负号，很多人都没彻底搞懂

tail -n 100 app.log 表示查看文件最后 100 行，这是最常用、也最不容易出错的写法。但 tail 还有另一种很容易混淆的用法：tail -n +100 app.log。

这个 +100 表示的不是“最后 100 行”，而是“从第 100 行开始，一直显示到文件末尾”。如果你刚开始接触时没注意这个加号，后面很可能会在使用时翻车。我记得有一次帮同事看脚本，他把 tail -n +1 当成“最后一行”，结果脚本输出从第一行开始到最后一行，自然什么都看不出来。

搞清楚这个之后，很多场景就会非常方便。比如你处理一个分片日志，已经确认前面 200 行都是程序启动时的冗余信息，你想跳过这 200 行直接看后面的新日志，写成 tail -n +200 app.log 就可以了，不需要先去统计总行数，再算差值。

2.2 -f 和 -F：一个字母之差，日志轮转时差别巨大

tail -f 可能是所有运维人用得最多的实时跟踪参数。tail -f app.log 启动后，屏幕会停在那里，文件有新内容写入时自动显示出来。它适合调试接口、观察服务启动过程、确认定时任务是否正常跑完。

但我必须提醒你：如果是长期运行的监控脚本，或者你接管了一个会用 logrotate 按天切分的日志目录，那 tail -f 会坑你。

举例：

bash复制tail -f /var/log/myapp/app.log

假设系统在凌晨 00:00 执行 logrotate，把当前 app.log 重命名为 app.log.202