在Linux终端里摸爬滚打这些年，如果让我从常用命令里挑一个最被低估、却又最高频用到的，我大概率会选head。你测试一个新接口返回的响应，可能只需要看前几行；你在排查一个几GB的日志文件，不会傻到直接cat，第一反应往往是head先瞄一眼。head这个命令从名字就能看出来，就是取一段内容的头部，它简单到三分钟就能学会，但在脚本里用得好，能省下一大堆不必要的IO和调试时间。这篇文章适合Linux初学者、运维工程师、后端开发，以及正在准备Linux面试的朋友，我会把head的核心参数、实战组合用法、还有那些文档里不会写的坑，一次讲透。

1. 先说结论：head命令到底解决什么问题

1.1 一个场景让你记住head

先说一个我印象很深的例子。有次线上服务半夜报警，登录到机器上后，我第一件事不是去看监控面板，而是打开服务启动日志，用head -n 30看了它的前30行。为什么看前30行？因为很多服务在启动时会打印版本号、加载的配置文件路径、初始化参数，这些信息全部集中在日志最开头。如果启动阶段就已经出错，比如配置文件路径写错、依赖的端口被占用，你在日志头部一眼就能看到异常。那次恰好是配置文件里多了一个非法字符，head扫过去几秒钟就锁定了问题，连日志搜索都不用做。

如果你用cat打开一个几百MB的启动日志，不是不行，但输出瞬间会占据整个终端，之前的屏幕记录全被冲掉，你反而更不容易看到最前面的关键信息。head相当于帮你把“开头”单独拎出来放在桌上，其他内容先不碰。这种“先看关键部位”的思路，在处理任何大文件时都成立，而且越是大文件，head的这个价值就越明显。

再说一个不太起眼但很实用的场景：很多命令的输出，第一行是标题行。比如ps aux、ls -l、df -h，这些命令的输出第一行都是列名称。如果你想快速确认某个输出里有哪些列，直接ps aux | head -n 1 就够，没必要把整页输出全拉一遍。如果你发现某个命令输出顺序乱了，先用head看标题行，往往能帮你快速理解每一列的含义。

1.2 head与cat、tail、less的分工

在刚学Linux的时候，最容易混淆的是head、tail、cat、less这几个命令。它们都能查看文件内容，但侧重点完全不同。我习惯用这张表来理解：

实际使用中，cat是最容易被滥用的。很多人一上来就cat大日志，结果屏幕疯狂刷新，旧内容根本看不清；如果文件里有特殊控制字符，终端还可能出现乱码甚至短暂卡死。head和tail的价值就在于“按需读取”，避免一次把数据全倒出来。核心思路很简单：你只需要文件的一小段，就只读那一小段，不要贪多。

head和tail是一对镜像，但它们的应用场景差异很大：tail因为经常和-f一起用，成了日志追踪的标配；head则更多用于“抽样确认”。举个例子：你收到一份第三方提供的接口文档，文件是Markdown格式的，你想快速确认它的结构，head -n 50先看目录和前几节，比用编辑器打开更省事。

less的优势是交互式，你可以随时按/搜索关键字，按G跳到底部。但如果只是想知道文件开头写了什么，head显然更轻快，而且head的结果可以直接作为下一个命令的输入。less偏向人机交互，不适合在管道里串联。现在很多工具的--help输出特别长，less一页还看不完，我反而更常用cmd --help | head -n 30来快速看前几个参数。

1.3 基本语法：三分钟上手

head的语法非常规整：

head [选项] [文件...]

如果不加任何选项，head默认显示文件的前10行。这个默认值一定要记住，因为很多面试题就喜欢在这里挖坑：问head默认显示几行，回答5行的十有八九是记混了。tail默认同样是10行，不是5行，这俩千万别搞反。

最常见的调用方式是：

head -n 5 /etc/passwd

这条命令会显示/etc/passwd的前5行。它等价于旧的写法head -5 /etc/passwd。不过我个人建议在脚本和示例里统一使用-n 5这种写法，语义清楚，也更容易扩展。如果同时指定多个文件，head会在每个文件内容前打印一个形如“==> 文件名 <==”的标题块，告诉你当前看的是哪个文件。比如head -n 2 /etc/passwd /etc/group，输出里就会带上文件名标识。这个行为由-q和-v参数控制，后面专门讲。

值得注意的一个点是，head默认读取的是文件开头，不会对文件做任何修改。它和cat都是只读操作，放心用。很多人刚接触时，以为head命令会“截断”文件，其实完全不是。真正会截断文件的命令是truncate，或是重定向符>，head只是一个阅读工具。

2. 核心参数拆解：-n、-c、-q、-v

2.1 -n：按行取内容

最常用的参数就是-n。它后面跟一个数字，表示取多少行。head -n 100 表示取前100行，head -n 1表示只取第一行。这个参数看起来简单，但有几个细节需要留意。

第一个细节是：当数字前面有负号时，head的GNU版本会把它解释成“除了最后N行之外的所有行”。比如：

head -n -5 /etc/passwd

这条命令会输出/etc/passwd的全部内容，但把最后5行去掉。如果你事先不知道这个语法，看到命令可能会一头雾水。这个特性在GNU coreutils环境里可用，比如常见的Ubuntu、CentOS、Rocky Linux；但在某些精简环境或BSD系统上，行为可能不一致。跨平台脚本里，建议不要依赖这种负数写法，老老实实用head -n N截取前N行，要去掉末尾N行可以用sed代替。

第二个细节是：head -n 0 的结果是什么？它会输出空内容，什么也不打印。别小看这个写法，在一些脚本里你会用它来“消费”上游命令的输出而不保留内容，效果类似于把输出丢弃，但更明确。不过更常见的丢弃输出方式是重定向到/dev/null，这里提一下就好，实际用的频率并不高。

第三个细节是：很多人以为head -n 100会先把整个文件读完再挑前100行，其实不是。head是流式读取的，它逐行读取，只要凑够指定的行数，就立刻停止读取，不再继续向后扫。这一点在管道里尤其重要，比如head从tail -f或curl的持续输出中取够行数后，head会退出，同时管道上游进程会收到一个SIGPIPE信号。后面在问题排查部分我会专门展开讲。

2.2 -c：按字节取内容

有些时候你要的不是几行，而是固定长度的字节。比如从一个二进制文件里提取文件头，或者测试环境里生成一个固定大小的文件，head -c就派上用场了。

head -c 512 /path/to/file

这条命令输出文件的前512个字节。你也可以加上单位后缀，比如head -c 1k、head -c 2M，GNU coreutils都支持。注意这里的大小写：在GNU实现中，k和M分别表示1024，G表示1024的3次方；但如果你明确想用1000进制，可以用KB、MB这样的写法，具体要看实现。日常运维里直接用1k、1M最常见。

用head -c生成固定大小文件的例子：

head -c 1M /dev/zero > /tmp/1m.img

这会生成一个正好1MB的文件。如果你没有head，通常要借助dd：dd if=/dev/zero of=/tmp/1m.img bs=1M count=1。head -c的写法更短，但它的灵活性不如dd，比如dd可以指定起始偏移量，head -c只能从头部开始。所以真要做精确的二进制拷贝、跳读，还是回到dd，head只适合快速取前面一小段。

按字节取内容还有一个容易踩的坑：如果文件是UTF-8编码，而你要按字节截取，可能会把一个多字节中文字符拦腰截断，导致输出内容尾部出现乱码。比如“中”这个字的UTF-8编码是3个字节，head -c 1读到的是第一个字节，终端最终显示就会变成乱码或问号。处理文本时，能用行就用行，除非你明确知道自己要多少字节。

2.3 -q和-v：控制多文件输出

当head后面跟了多个文件时，默认行为是先打印一个文件名标题，再打印内容。这个设计在多数情况下是贴心的，但如果你想纯粹拿内容去喂给下一个命令，标题行反而会碍事。此时用-q（quiet）参数关闭文件标题：

head -q -n 1 /etc/passwd /etc/group

这条命令会把两个文件各自的第一行连续打印出来，中间不加任何文件名。反过来，如果你只想看某个文件，但希望head强制打印文件名标题，可以用-v参数。默认情况下，只有多文件时才打印，单文件不打印，v可以打破这个默认。

这两个参数不算高频，但在脚本里很实用。比如你要遍历一批配置文件的第一个非注释行，用-q把标题去掉，后续grep、awk处理起来更干净。注意，q和v是互斥的，同时使用时的优先级在不同版本的coreutils里可能不完全一样，所以我不建议你在一条命令里同时写-q和-v，那样写出来的命令别人读起来也容易糊涂。

2.4 顺带分清head这个词的其他领域含义

如果你在搜索引擎里输入“Linux head”，有时候会看到无关的内容，比如“yolov8 head改进”。这里我简单把几种常见的“head”含义区分一下，免得绕弯路。

第一，Linux命令head，就是我们这篇讲的文件取头部工具。第二，在文件系统或磁盘语境里，head也可能指磁头（hard disk head），或者分区表结构中的头部区域，这些和head命令是完全不同的概念。第三，在深度学习目标检测模型里，比如YOLOv8，Head指的是检测头，负责从特征图里预测目标的类别和位置。那里说的“Head改进”指的是网络结构改动，跟你在终端敲的head没有关系。

明白这些区别后，你看到“Linux head”不会再把网络结构和命令行混为一谈。尤其是做运维又接触AI的朋友，看到同一个词出现在不同技术栈里，第一反应应该是“这是哪个领域的head”，而不是硬套自己已知的概念。

3. 实战：head在日志排查和脚本里的组合用法

3.1 用head快速定位程序启动日志

生产环境里，日志文件越大，越需要先用head建立全局印象。比如你接手一个别人留下的服务，不知道它怎么启动的、依赖什么配置，那就可以先看看启动日志的前几十行。

head -n 50 /opt/app/logs/startup.log

很多服务启动时会打印Java版本、Spring Boot的Banner、监听端口、加载的配置文件等。这些信息都集中在日志头部。我遇到过一种情况：日志文件大小有2GB多，但实际有效启动信息就是最前面的几千行，后面全是重复的空指针异常。用head -n 2000先取出开头两千行，再配合grep -E 'ERROR|Exception'过滤，很快就能定位到第一处异常发生的位置。

这里有一个经验：如果日志文件已经被logrotate轮转，比如文件名是app.log.1，这个文件可能还是文本格式；更老的可能是app.log.2.gz这样的压缩包。对于.gz文件，不能直接head，因为读出来是一堆压缩乱码。正确姿势是先用zcat解压再交给head：

zcat app.log.2.gz | head -n 20

注意，这种写法会把整个压缩文件解压并通过管道传输，head只取前20行，实际消耗在解压上的时间通常也不会太久，因为数据不需要全部写出。但如果是超大压缩文件且解压本身耗时，也可以先用zgrep直接搜索关键内容，不必先head。自己心里要有数：zcat相当于解压，head再截断，整个过程是流式的，不是把整个解压结果落到磁盘上再处理。

3.2 用head截取CSV样例并保留表头

做数据分析或数据迁移时，经常需要从一个大CSV文件里抽出一小段样例来测试流程。很多人的第一反应是直接head -n 1000 data.csv > sample.csv。这样确实能得到前1000行，但如果CSV有表头，且你只想保留前999行数据加表头，这个方法就不够灵巧。

最简单的方式其实是多取一行：head -n 1001 data.csv > sample.csv，如果你要的是“前1000条数据+表头”，那总共就是1001行。如果文件尾部有汇总行，比如最后一行的合计，那还需要小心，不过多数CSV没有汇总行。

另一种更精细的做法是组合head和tail：

head -n 1001 data.csv | tail -n 1000 > sample.csv

先从大文件取前1001行，再从中取最后1000行。如果第一行是表头，这1000行就包含表头和999条数据；如果你想去掉表头，可以用tail -n +2再处理。这里的关键是理解head和tail都支持把管道数据当作输入，形成“切片”。

如果需要同时把表头单独存成一个文件，可以这样：

head -n 1 data.csv > header.csv head -n 1001 data.csv | tail -n 1000 > body.csv

这样表头和数据文件都拿到了，后续用pandas或awk处理都方便。实际写脚本时，我习惯先验证行数：wc -l sample.csv，确认一下没有把表头弄丢，也没有把文件尾部的空行带进来。

3.3 head与管道、grep、curl的复合用法

head最常见的搭档是管道。任何命令只要输出到标准输出，都可以用head截断开头的若干行。最常见的例子是ps：

ps aux | head -n 6

这会显示标题行加前5个进程。如果你只关心CPU占用最高的几个进程，可以配合sort：

ps aux --sort=-%cpu | head -n 6

注意这里head截断的是sort排序后的前几行，逻辑顺序是先排序再取头，不是先取头再排序。这个顺序一旦搞反，结果就完全不一样了。

再看一个网络接口的例子。调试HTTP接口时，如果不想下载完整响应，只想看前几行，可以：

curl -s http://example.com/api/data | head -n 10

curl会持续读取响应，但只要head取够了10行并退出，curl在继续写输出时就会收到SIGPIPE信号而停止。这样既能看到响应开头，又不会把整个响应都拉下来。在目标接口返回内容非常大的时候，这个用法能省很多时间和带宽。

还有一个很实用的场景，grep配合head控制匹配结果数量。比如你要在日志里找最近的报错，但不希望一次输出几百条：

grep -m 5 'ERROR' app.log | head -n 5

grep -m 5本身已经限定最多匹配5行，head在这里相当于双保险。如果你不写-m，grep会扫完整个文件再输出，head虽然尽早退出，但grep仍可能继续扫描，所以配合-m从源头控制更高效。

再比如用awk处理文本后取头部：

awk -F: '{print $1, $3}' /etc/passwd | head -n 5

这条命令先提取用户名和UID两列，再只显示前5行，样例非常清晰。想查看系统启动日志时，也可以直接dmesg | head -n 20，只看内核开机阶段最早输出的那部分信息。总之，head就像是一个“水龙头”，把上游想让你看到的输出控制在你指定的行数内。

3.4 批量多文件取头：head file*.log

运维脚本里经常要快速浏览一批同类文件的开头。比如有多个应用节点的日志，你想看看它们的启动配置是否一致：

head -n 5 /var/log/app/node*.log

head会依次处理每个文件，并在每个文件内容之前加上文件名提示，输出类似：

==> /var/log/app/node1.log <== ... ==> /var/log/app/node2.log <== ...

这个文件名提示非常方便，但如果你想把所有头部内容合并后再做下一步处理，需要去掉提示，用-q参数：

head -q -n 5 /var/log/app/node*.log | grep 'port'

这样就只会输出匹配到port的行，不会带着文件名杂乱信息。实际上在巡检脚本里，我经常用这个组合来检查一批配置文件的关键参数是否存在，比用编辑器一个个打开效率高得多。

还有一个小技巧：当文件很多时，head的默认输出会很长，你可以在外层再加一个head来限制总行数：

head -n 20 /var/log/app/node*.log | head -n 20

内层head是每个文件取20行，外层head再对合并结果取前20行，适合只扫一眼。如果你要写更严谨的巡检脚本，可能还要配合循环、判断返回值，但至少从“人工快速确认”的角度，这套组合已经够用了。

4. 常见问题与避坑记录

4.1 大文件读取为什么快？关于管道SIGPIPE

这是面试里经常被追问的点：为什么head读取大文件很快？因为head是流式读取，读够需要的行数后，立即关闭输入并退出，不会傻傻地把整个文件读完。比如head -n 1一个10GB的文件，它只会读取到第一个换行符就结束了，实际读入的数据可能只有几十字节。这个特性让head在处理超大文件时性能极好。

但和管道一起用时，这个“提前退出”会带来一个副作用：管道上游的命令还在拼命写输出，下游的head却关闭了管道，上游再写时就会收到SIGPIPE信号，默认动作是终止进程。我们刚才提到curl，当服务端持续推送数据时，curl会因为SIGPIPE而退出，这是预期行为。但如果你在一个重要脚本里把head放在管道下游，上游是一个需要完整收尾的程序，那SIGPIPE可能会让上游中途退出，产生意料之外的结果。

举一个反例：

cat largefile | head -n 5

这种写法很常见，但我个人不太推荐。因为cat会从头到尾读取文件并写入管道，而head只取5行后就关闭管道，cat大概率会收到SIGPIPE退出。虽然结果一样，但它白白读取了大量数据，不如直接head -n 5 largefile。记住一个原则：能用head直接读文件，就不要cat再交给head。管道确实很强大，但别为了打管道而打管道。

4.2 从第N行到第M行：head与tail联合

虽然没有一个专门的命令叫middle，但想取出文件中间的一段，用head和tail组合很容易实现。假设要取文件的第100行到第200行：

head -n 200 file | tail -n 101

为什么是101？因为100到200一共是101行。head先取前200行，tail再取其中的最后101行，也就是第100到第200行。这里最容易算错的就是行数差一。如果你写tail -n 100，会少一行。我建议每次写这类命令前先数一遍：end-start+1。

更灵活的方案是用sed：

sed -n '100,200p' file

sed直接指定行号区间，可读性更好，也避免了组合命令的偏移计算。但在面试时，面试官想考察的往往是你是否理解head和tail的组合逻辑，所以这两种方案你都要会。

还有一个衍生场景：取第10行之后的全部内容。可以用tail -n +10表示从第10行开始到末尾，也可以用sed -n '10,$p'。但head做不到“从第10行开始”，它只能从头取。理解这个边界，才能在不同需求里选对命令。

4.3 碰到乱码与二进制内容怎么处理

用head查看文本文件，偶尔会出现乱码。最常见的原因是文件编码和终端设置的字符集不匹配。比如文件是GBK编码，而终端是UTF-8，直接head出来就是一堆乱码。此时并不需要换命令，先确认编码再转换：

file -i filename

file命令会告诉你文件的字符编码，再用iconv转一下：

iconv -f GBK -t UTF-8 filename | head -n 20

如果是二进制文件，head -n按行读取会把二进制内容按文本处理，终端可能显示各种奇怪字符。这时你应该改用head -c取若干字节，再用xxd或od转成十六进制：

head -c 16 file.bin | xxd

这个组合可以快速查看文件的magic number。比如一个PNG文件的前8个字节通常固定为89 50 4E 47 0D 0A 1A 0A，你用xxd一看便知。遇到不知道类型的文件，file命令本身也会读取文件头来判断，原理类似。这个技巧在处理二进制协议、解析未知文件时很实用。

4.4 Linux面试里head的高频考点

把我在面试和笔试里见过的head相关题目按频率排个序：

第一，head默认显示几行？答案是10行。很多人会回答5行，因为误把默认行数和-n 5记串了。第二，-n和-c的区别？-n按行，-c按字节。如果面试官追问，问到UTF-8中文字符截断问题，能答出来会很加分。第三，如何用head和tail取文件的中间某一段？核心是end-start+1这个偏移计算。第四，head在管道中是如何影响上游进程的？能答出SIGPIPE，说明你有实际运维经验。第五，遍历多个文件时，如何抑制文件名提示？使用-q，对应地强制打印用-v。第六，head -5和head -n 5有什么区别？旧式语法，GNU里等价，但新脚本建议使用-n 5。

这些问题覆盖面不大，但每一个都对应一个具体的踩坑点。把这些记牢，面试时被问到head就没问题了。其实面试官问这些并不是为了难为人，而是想确认你到底有没有在真实环境里操作过，而不是只背过命令手册。

最后分享一点个人感受。我处理问题有一个习惯：拿到一个陌生的日志文件，不是先搜错误，而是先head三五行，看看这个文件是不是我想象中的那个文件。很多线上事故其实是“看错日志”引起的，比如看了旧轮转文件、看了另一个应用的日志，导致排查方向完全跑偏。head可以帮助你在第一时间确认文件身份：开头打印的往往是进程名、日期、版本，一眼就知道有没有看错。这个习惯救过我很多次，希望你也能养成。至于head还有什么高级玩法，其实你掌握这些之后，剩下的就是在真实需求里自然生长了。