Linux man命令完全指南：从查询手册到自定义手册页

1. 为什么老手还在用man，而新手总在百度

先问一个反直觉的问题：Linux命令帮助信息，最好的来源是什么？

不是百度，不是谷歌，不是各种“Linux命令大全”的博客合集，而是系统里几乎每一台机器都自带的一本线下手册——man命令。

我见过太多初学者，一遇到不会用的命令就打开浏览器搜“xxx命令用法”，搜出来的文章质量参差不齐，有的甚至拿CentOS 6的过期写法来教CentOS 9，参数对不上、路径对不上，照着敲半天报错一堆。其实你手里就有一份和当前系统完全匹配的官方文档，man命令的说明内容和内核、工具链保持同步，系统升级了文档也跟着变，不会出现“网上教程说能用但本机就是跑不通”的尴尬。

man是英文“manual”的缩写，直译就是“手册”。它背后是一整套完整的手册分页系统，不只是给命令看，配置文件、系统调用、标准库函数、设备驱动、文件格式、游戏命令、系统管理命令，都能通过它查询。很多人在Linux上摸爬滚打几年，始终停留在man ls、man grep这种最浅层的用法，这篇文章我想把man命令从查参数到搜文档、从看帮助到自定义手册页，系统性讲透。

如果你是个刚接触Linux的新手，这篇文章能帮你养成一个好习惯——遇到命令先翻本机手册，而不是满世界找教程。如果你是个有一定经验的运维或开发，这里面关于搜索语法、阅读器配置、自定义手册页的内容，应该能给你一些之前没用起来的思路。

man命令的另一个价值是它天然离线可用。你不需要联网，不需要翻文档站点，不管是在一台没有外网的生产服务器上排查问题，还是通过SSH远程登录到一台极度精简的容器里，只要系统里有这个命令的基本组件，man永远是你最可靠的帮手。对运维来说，这个特性在故障处理场景下简直是救命稻草。

下面我从头开始，按我自己的理解把这个命令拆开讲。

2. man手册的分区结构：为什么同一个printf有两个帮助页

先把最重要、也最容易被忽略的一个知识点讲清楚：man手册是分区的。

很多初学者第一次用man printf，发现出来的内容和C语言里的printf()函数完全不沾边，这是因为man默认找到的是“shell命令printf”，而不是“C库函数printf”。这种情况就涉及手册分区。

Linux手册页按内容划分为9个区段（section），不同发行版略有差异，但整体结构基本一致：

理解了分区之后，再回头看man printf的问题：shell环境里有个printf命令，属于用户命令，所以默认查的是第1区；如果你想查C语言的printf()函数，得指定区段编号：

bash复制man 3 printf

同理，man open默认查到的是第1区的命令open，第2区的open()系统调用得用man 2 open才能看到。man man的手册页里，第一段就明确写了“The table below shows the section numbers of the manual followed by the types of pages they contain”，但说实话，没几个人会认真读这段，绝大多数人第一次操作时就是直接踩坑。

怎么确认当前系统里有哪些分区？直接在终端跑下面这条命令：

bash复制man -w printf

或者用man -a printf，这个参数会把所有区段里匹配“printf”的手册页依次显示出来，看完一个按q退出，然后继续看下一个。如果你只想知道某个命令或函数是否存在，man -W是个更轻量的选项，它不显示内容，只输出目标手册页的文件路径：

bash复制man -W printf

返回多个路径说明这个名称在不同区段都有定义，这对于判断“到底有几个同名手册页”非常直观。

还有一个常用场景：你想知道某个命令属于哪个区段，不想一个个试，可以这样：

bash复制man -f ls

这条命令等价于whatis ls，会从whatis数据库中读取ls的简要说明。如果提示“nothing appropriate”，说明当前系统的whatis数据库还没有建立，可以先执行mandb手动构建索引（部分发行版命令叫makewhatis）。

把分区这个概念搞明白之后，你会发现man的文档就像一本工具书的目录，先知道去哪一章找答案，比打开书乱翻要高效得多。

3. 搜索才是man的精髓：从memorize到locate

大多数人用man，是拿着已知的命令名去查参数。但你有没有反过来想过：如果我只记得某个命令大概能做什么，但不确定它叫什么名字，怎么找？

假设你想找一个能压缩文件的命令，但脑子里只记得“zip”这个词，不记得gzip还是bzip2还是xz，这时候man -k就派上用场了：

bash复制man -k zip

这条命令等价于apropos zip，它的工作机制是在whatis数据库中做模糊匹配，把所有名称或描述中包含“zip”的手册页都列出来。你会看到gzip(1)、zip(1)、unzip(1)、zipinfo(1)等一堆候选，每一条自带一句话简介，你扫一眼就能定位到正确的命令。

man -k的匹配是基于子字符串的，不需要精确匹配，所以man -k "copy file"这种带空格的搜索也能执行，但注意引号的作用是让整句作为一个关键字去匹配。如果想更灵活，还能结合正则表达式：

bash复制man -k "^net"

这条会搜索描述字段中以“net”开头的所有手册页。搜索正则的规则遵循POSIX扩展正则表达式，你能用的. * ^ $ []这些符号在man -k里都有效，这让它的搜索能力大大增强。比如想找所有和权限相关的命令，可以这样：

bash复制man -k "permission|chmod|chown"

匹配描述中含“permission”或“chmod”或“chown”的手册页。注意有些系统的apropos实现不支持|这种扩展分支，需要先确认你用的grep风格是什么。在常见发行版上，man-db实现的-k选项默认支持扩展正则，实测下来是没问题的。

还有一个类似但结果不同的小兄弟：man -f。它不做模糊搜索，只做精确的名称匹配，等价于whatis命令。上面提过，man -f printf直接告诉你printf是哪个区段的页面，不会把一大堆相关命令都倒出来。

再进一步说，whatis数据库是一个纯文本的索引文件，不同的发行版存储位置略有差异，常见路径是/var/cache/man/whatis或/usr/share/man/whatis。这个数据库可以通过mandb命令手动重建，如果你发现自己man -k搜出来的结果明显滞后于系统已安装的软件，那就跑一次：

bash复制sudo mandb

重建过程会扫描所有MANPATH路径下的手册页，生成新的whatis索引。这个操作在生产服务器上建议在低峰期执行，因为全量扫描可能会有一定IO开销，不过对于普通机器来说，也就几秒钟到几十秒的事。

到这里，搜索逻辑已经覆盖了“忘了命令全名能从关键词找命令”“知道命令名想确认它在哪个区段”这两个高频场景。剩下的问题，就是拿到手册页之后，怎么在里面快速定位到你关心的内容。

4. 进入man页面之后：用less的搜索和导航技巧提升效率

man默认使用的翻页器是less。这也是为什么你在man页面里看到的操作和less查看文件时几乎一致——上下翻页、搜索、跳转，全部继承自less。

很多教程只教你/keyword搜索、n和N跳转上一条下一条，这些确实是核心操作，但实际用的时候还有几个效率翻倍的小技巧值得单独拿出来说。

首先是搜索时的高亮开关。less默认会对匹配到的关键字做高亮显示，如果你发现搜出来的关键字没有高亮，看看是不是less的-g或-G选项被设置了。临时打开高亮的按键是Ctrl+G组合中的G不好使，准确的说是按G跳到文件尾部，跟高亮没关系。要在当前会话里开关高亮，按-g键，然后在底部提示符输入g或G即可切换。更直接的办法是在man命令启动时就传入less的选项：

bash复制man --pager="less -g" ls

让兼容性最好。再比如你想改变搜索的匹配模式，不区分大小写，可以按-i键，less会提示你输入i来切换大小写敏感设置。这一串快捷键不用背，只需要记住一个思路：man的阅读器本质上是less，less的所有交互命令在man界面里都能用，遇到问题按h查看less自身的帮助说明。

其次是一个经常被忽略的导航功能：直接跳到某个区段的关键词位置。比如你在查看man bash，这份手册页有几千行，你想看“循环结构”相关的内容，可以直接输入/loop搜索。但如果你知道这部分内容通常在某个编号的帮助区域里，也可以利用less的“内容定位”功能跳转。不过说实话，对于绝大多数人来说，/关键字配合n/N已经是最高效的信息定位方式了。

第三是man页面里的超链接。man-db生成的页面可以识别“see also”区块中的交叉引用，部分终端支持用鼠标点击，或者通过快捷键跳转。不过这个功能在不同系统上体验差异很大，我不推荐把它作为主要导航手段，知道有这么回事就行。

翻页器的使用效率直接影响你查手册的体验。我见过不少人查man tar，内容出来后从头一页页往下翻，翻到一半发现选项有几百个，早忘了前面看过什么。正确姿势是先定位再精读：进入页面后，如果你要找某个具体参数，比如tar的-z选项，直接/ -z 搜索，注意后面带一个空格防止匹配到-zz之类的子串，搜到之后按n跳到下一个匹配，直到找到你要的那条说明。看完按q退出，整个过程不超过十秒。

另外，man支持定义阅读器的启动参数，很多人不知道man可以通过MANPAGER环境变量来指定自己习惯的阅读器。比如你更喜欢用vim来看手册页，可以这样配置：

bash复制export MANPAGER="vim -R"

-R是只读模式，防止误改文档内容。不过我个人还是建议用默认的less，毕竟less针对屏幕阅读做了很多优化，vim的话你还要处理分页符和退格控制字符，属于给自己找麻烦。

对于长文档，还有几个实用的快捷键：

• gg：跳到文件头部
• G：跳到文件尾部
• 50%：跳到文档的50%位置，适合查看手册页这种有明确章节划分的长文本
• Ctrl+F：向下翻一屏
• Ctrl+B：向上翻一屏
• !man：临时在man内部执行一个shell命令，比如!date看当前时间，按回车返回

这些快捷键不要求全会，但gg和G对长文档非常实用，建议刻进肌肉记忆。

5. 自定义MANPATH与手册页的“第二来源”

默认情况下，man命令从哪里找手册页？这个问题可能很多人没仔细想过。man的搜索路径由MANPATH环境变量控制。如果没有显式设置，man会读取默认路径，常见的包括/usr/share/man、/usr/local/share/man等。不同发行版的具体路径有差异，但大方向一致。

如果你自己编译安装了一个新软件，装到了自定义前缀目录比如/opt/mytool，那它配套的手册页通常会被安装到/opt/mytool/share/man。这个路径不在默认搜索范围内，直接man mytool大概率会提示“No manual entry for mytool”。解决办法有两个：

方式一，单次会话内临时添加路径：

bash复制export MANPATH="/opt/mytool/share/man:$MANPATH"

注意这里的变量顺序。man在搜索时按MANPATH中路径的先后顺序查找，排在前面的路径优先匹配。如果你有两个同名的老版本和新版本工具分别装在不同目录，想把新版优先展示，就把新版的路径放前面。

方式二，写入用户级配置，永久生效：

bash复制echo 'export MANPATH="/opt/mytool/share/man:$MANPATH"' >> ~/.bashrc
source ~/.bashrc

还有第三种方式，不修改MANPATH，用-M选项临时指定搜索路径：

bash复制man -M /opt/mytool/share/man mytool

适合一次性查询，不做永久改动。

这里还要提一个容易踩坑的点：如果你手动设置了MANPATH环境变量，man可能会忽略系统默认的手册页路径。不同man实现的行为有差异，GNU的man-db在检测到MANPATH非空时，会完全按照你给的值去搜索，而不是“自定义路径+默认路径”取并集。所以如果在设置MANPATH后，发现man ls都找不到页面了，说明系统默认路径被你的自定义值遮蔽了。解决办法是把默认路径显式加回去：

bash复制export MANPATH="/usr/share/man:/usr/local/share/man:/opt/mytool/share/man"

怎么确认当前man实际使用的搜索路径？直接执行：

bash复制man -w

不带参数时它会输出当前生效的MANPATH路径列表。或者用man --path，效果相同。这个命令在排查“为什么我man不到某个命令”时非常有用，我强烈建议你先跑这个看路径是否覆盖到位。

说完了路径，再讲一个进阶玩法：自定义手册页。你可以把自己的脚本、项目工具写成标准man格式的文档，放入MANPATH中的任意目录，之后就能用man命令查阅。man格式的本质是排版宏语言，最简略的手册页只需要这几行：

groovy复制.TH MYTOOL 1 "2024年1月" "v1.0" "My Tool Manual"
.SH NAME
mytool \- a demo tool for testing man pages
.SH SYNOPSIS
.B mytool
[\fIOPTION\fR]...
.SH DESCRIPTION
.B mytool
is a demonstration tool.

把这堆内容保存为mytool.1，放到/usr/local/man/man1/目录下（如果目录不存在先创建），然后执行sudo mandb更新数据库。之后运行man mytool就能看到这个自定义页面了。

这个功能对团队内部工具非常有用。很多公司会有内部脚本，注释写得再清楚，过几个月去看也可能忘。如果把命令参数说明写成man手册页，和命令一起分发到所有服务器上，使用者在机器上直接man一下就能查，比翻wiki、翻Confluence高效得多。

还有一个和MANPATH相关的细节：man支持通过-S选项指定只搜索某个区段：

bash复制man -S 5 mytool

如果自定义的mytool同时有第1区和第5区的手册页，这条命令会强制只看第5区。这个参数在手册页跨区段的场景下很有用。

6. man文档的“窗口”参数：MANWIDTH与输出宽度

前面讲的分区、搜索、路径，都是切入手册页本身，现在说一个视觉层面的小细节：MANWIDTH环境变量。

默认情况下，less会根据终端窗口宽度自动做软换行，man手册页的内容在终端里能正常阅读。但有两种情况会让你觉得页面排版很奇怪：

第一种，终端宽度过窄。比如你在手机上用SSH客户端连服务器，或者终端侧边栏开得很窄，man页面会把每个长行拆成很短的片段，看起来支离破碎。第二种情况，终端宽度很宽，但man页面仍然用默认的80列宽度显示，右边空出一大片，看起来不协调。

MANWIDTH就是控制man输出宽度的环境变量，设置方式：

bash复制export MANWIDTH=120

这样less会按120列排版。如果你希望man始终使用终端当前宽度，可以设置：

bash复制export MANWIDTH=$(tput cols)

这条命令的动态逻辑是把终端列数作为宽度值传给man。不过注意，这行只影响设置时所在终端，如果想全局生效，还是得写进shell配置文件里：export MANWIDTH=$(( $(tput cols) - 2 ))，留出两列空余防止折行拥挤。

还有个相关的小技巧：man支持把手册页内容输出为纯文本格式，不经过less阅读器。方法是：

bash复制man ls | col -b > ls_man.txt

col -b会把反退格符等控制字符清除，得到一份干净的文本手册。这个操作在需要把手册页分享给其他人、或者导入到文档系统时很实用。同样地，如果你用man配合grep做筛选：

bash复制man ls | grep -A 2 "\-l"

这个命令会有问题，因为man输出的内容经过了groff格式化，包含大量控制字符，直接grep会看到一堆乱码。正确做法是先col -b再grep：

bash复制man ls | col -b | grep -A 2 "\\-l"

这里面\\-l是转义后的搜索模式，因为man源文件里参数会写成\-l，防止被格式化工具当作连字符。不同man实现对这个细节的处理不完全一致，我在Ubuntu上测试过，用\\-l能更稳定地匹配到选项说明。在实际应用中，像“把man输出转成文件放进企业内部知识库”“把man输出通过管道喂给后台脚本做关键字统计”，这类场景都需要先经过col -b清洗。

7. 语言与本地化：让man显示中文

很多中文用户希望man直接显示中文帮助。这件事的实现方式取决于系统是否安装了对应语言的手册页翻译包。

Debian/Ubuntu系统上可以安装manpages-zh，Red Hat/CentOS系则看man-pages-zh-CN等，安装后配合LANG环境变量切换语言：

bash复制sudo apt install manpages-zh      # Debian/Ubuntu
sudo yum install man-pages-zh    # CentOS/RHEL老版本

然后设置LANG=zh_CN.UTF-8，再执行man ls，如果一切正常就会看到中文手册页。不过这里有几个注意点：

第一，翻译覆盖范围有限。常见的核心命令（ls、grep、find等）有翻译，但很多软件包自带的手册页并没有中文版本，这时候man会fallback回英文，这是正常现象，不是配置错了。

第二，中英文混排时对齐可能不好看。man手册页是为英文设计的排版格式，中文翻译难免在缩进和表格对齐上有瑕疵，但能看懂内容才是最重要的。

第三，生产服务器不建议为了看中文而改LANG。很多服务端程序对LANG敏感，改动可能影响日志编码，我一般是在自己的开发机上装翻译包，生产服务器保持英文。

还有个思路是配合MANPAGER或MANOPT设置一个预处理管道，把英文手册页自动翻译成中文。不过这类工具目前还不够成熟，机器翻译的质量勉强能看，但专业术语经常翻错，例如“inode”会被翻成“索引节点”还算好，superblock被翻成“超级块”也还行，但有些工具会把“mount”翻成“安装”，造成严重误导。我不推荐在关键操作场景依赖机器翻译，老老实实看英文原版反而更准确。英文本身不是障碍，手册页的句式非常固定，动词就那么几个，看多了会发现翻来覆去就是那些表达方式，比读技术博客的英文容易得多。

如果实在想快速看懂某个手册页的核心内容，可以安装tldr这类社区维护的精简命令帮助工具。tldr不是man的替代品，它的定位是“快速给出手册中最常用的5到10个示例”，适合扫一眼直接抄作业。你完全可以把man和tldr结合用：先用tldr搞懂命令大概怎么用，再用man查具体参数的微妙差异。

8. man背后的机制：groff、宏包和格式化

前面所有操作都是在“使用”man，但如果你对man这个体系本身产生过好奇，这节我们来揭开它的黑盒。

man手册页的源文件是什么？它是一份用groff排版宏编写而成的纯文本文件。groff是GNU的排版系统，man宏包提供了一套专门适合手册页的排版命令。前面第5节写自定义手册页时就用到过，.TH、.SH、.B这些都是宏包提供的命令。

当执行man ls时，man背后做了几件事：

1. 根据MANPATH搜索ls的手册页文件，最终定位到/usr/share/man/man1/ls.1.gz（注意是压缩过的，为节省磁盘空间，手册页默认gzip压缩存储）
2. 解压内容，经过groff依据宏包格式转换处理
3. 将格式化后的内容输出给阅读器（通常是less）

所以你在man页面看到的效果，不是源文件的直接展示，而是经过groff渲染后的结果。这就是为什么直接cat一个man源文件会看到一堆以点开头的魔法行，不像一份正常的阅读文档。

groff转换这个环节还衍生了一个实用技巧：把man手册页转成其他格式。不同发行版带有不同的转换工具，以下几种我实测比较常用：

转成PDF：

bash复制man -t ls | ps2pdf - ls.pdf

man -t输出的是一份PostScript，管道给ps2pdf就能生成PDF。在需要把手册页当作参考资料打印、或者在没有man环境的地方离线查看时，这个方案非常实用。我试过转PDF之后在平板上划重点看，体验比直接看终端好不少，毕竟排版和换行都固定下来了。

转成HTML：

bash复制man -H ls

这个命令在带图形界面的Linux或macOS上会直接打开浏览器显示HTML版本的手册页。不过-H依赖浏览器环境，纯SSH终端下用不了，此时可以借助mandoc工具（如果有安装）配合转换：

bash复制mandoc -T html ls.1 > ls.html

知道了机制，你就能理解为什么man文档的内容权威性那么高：它和当前系统里的命令是一对一的对应关系，文件路径、默认配置、支持的特性，都和发行版打了同样的补丁。网上的教程写于什么系统版本、什么软件版本，根本说不清楚，自然没法保证准确性。

groff这个体系虽然古老，但极其稳定，几十年下来接口变化很小。你在2024年的系统上查看一个1990年代编写的man页面，仍然能正常渲染，这种向后兼容能力是很多现代文档系统做不到的。这也是为什么man能一直活到今天，没被Web文档取代的原因之一。

9. 实战中的一些小例子与踩坑记录

理论讲了不少，这节放几个我在实际工作中用man处理过的场景，顺便记录几个踩过的坑，帮你少走弯路。

9.1 查一个命令的退出码含义

写脚本时经常要判断命令是否执行成功，但很多命令的退出码不止0和1。比如grep，0表示找到匹配，1表示没有匹配，2表示文件不存在或权限不足。如果你忘了grep的退出码约定，man grep到“EXIT STATUS”一节就能看到完整说明。

技巧是直接搜/EXIT或/STATUS，快速跳过去，不用把整个手册翻一遍。

9.2 配置文件语法不清楚时查第5区

/etc/rsync.conf、/etc/ssh/sshd_config这类配置文件的语法，不在命令手册里，而在第5区。比如你想确认sshd_config里PermitRootLogin的合法值，直接：

bash复制man 5 sshd_config

然后搜PermitRootLogin即可。这个习惯可以帮你省下很多搜博客的时间，毕竟博客里的配置片段常常不完整，而第5区文档对该文件的所有选项都有详细解释。

第5区是一块被严重低估的宝地。大多数用户知道man 1和man 8，知道man 3和man 2是程序员用的，但man 5对于写配置文件的运维人员同样关键。配置文件写错一句，服务起不来，与其去百度“xx配置文件参数说明”，不如直接查第5区——这上面记录的是这个文件本身的结构、每个字段的取值范围、默认值和作用，准确性无出其右。

9.3 踩坑：man -k 搜不到刚装的软件

有次我在服务器上装了nload（一个网络流量监控工具），装完想用man -k network搜一下相关命令，结果列表里没有nload。原因在于whatis数据库没有被更新。

解决方式前面提过，跑一遍sudo mandb重建索引，再搜就能看到了。这个坑在Debian/Ubuntu系比较常见，因为man-db默认不会实时更新whatis。Red Hat系有些版本装包时会自动触发mandb，体验稍好，但也不能完全依赖。

9.4 踩坑：奇怪的字符导致搜索失败

在man页面里搜选项时，-l这种以横线开头的字符串，直接/-l去搜可能搜不到，因为groff在渲染时可能把一些字符做了特殊处理。我自己的经验是搜索时多用\\-代替-：

bash复制/\-l

这样匹配更加稳定。之前在第6节提过这个细节，这里再单独列出来，因为它是实际使用中遇到频率最高的一个搜索问题，不少老手也被坑过。

9.5 查内核相关信息

查内核参数、设备驱动等偏底层的资料，可以试试查第4区和第9区。比如你想看Linux随机数设备/dev/random的行为说明：

bash复制man 4 random

这类页面提供了很多令人意外的背景知识，比如熵池、阻塞与非阻塞模式的行为差异，比看二手资料的博客舒服得多。

9.6 使用man的“帮助”-h辅助

如果你进入man页面后不知道该怎么操作了，按h会弹出less的帮助文档。这个帮助文档是less自身的完整说明，非常详尽。不过内容篇幅不小，新手看了容易懵。记住最核心的几个键就行：/搜索、n下一条匹配、N上一条匹配、q退出、gg跳转头部、G跳转尾部。其他的遇到具体问题再按h现查。

10. 把man变成自己的知识体系的一部分

回到开头那个问题：为什么老手还在用man？

因为它是最贴近系统实况的文档来源，没有延迟、没有版本错位、没有二手加工，它直接告诉你当前这台机器上这个命令的真实行为。

我自己的使用习惯是这样一个流程：第一次接触一个不熟悉的命令，先man扫一遍SYNOPSIS和DESCRIPTION，了解它到底是干什么的；然后tldr看一眼常用示例，快速上手；遇到具体需求时再回man精读相关选项。这一套流程下来，基本能覆盖90%的日常场景。

还有一个容易被忽视的点：man本身也可以查man。man man的页面里详细解释了所有选项、环境变量、退出状态。很多高级功能我都是查man man才发现的，比如-K全局搜索所有手册页的内容、-S指定区段搜索、--nh和--nj控制是否输出粗体/斜体，这些功能散布在它的文档里，有兴趣的可以自己探索一番。

如果要我总结，man命令的学习曲线并不陡峭，真正陡峭的是“习惯养成”这一段——遇到问题先去man而不是去搜索框。这个习惯一旦建立起，你会发现自己和Linux的默契程度会上一个台阶。毕竟Linux本身自带一本内容详尽的说明书，而很多人却宁愿在外面的论坛里翻来翻去找答案，还挺魔幻的。