很多刚开始接触 Linux 的朋友，都免不了背命令。今天记几个，明天忘几个，等真正遇到系统出问题，翻遍全网也找不到对症的命令，最后只能重启了事。这个系列我起名叫“医疗视角下的 Linux”，就是想换一套思路来学：把 Linux 当病人，把命令当诊断工具，把命令手册当诊疗参考。人看病找对科室、查对指标、开对药，Linux 排障也是同一套逻辑。这一篇，专门把“Linux 命令手册”从头到尾拆一遍。
先说结论：命令手册不是字典，不是让你一页页背单词的。它更像一本按科室分好的诊断指南——你不需要记住每种病怎么治，但要知道什么症状该翻哪一章，什么检查能确认什么疑点。真正的高手不是背过所有命令，而是能在系统“叫疼”的时候，几秒内定位到该用哪几条命令判断病情。这篇不讲那些花哨的运维大魔法，就把最常见的命令按“科室”分好，再配合一个完整排查案例，带你走一遍“医生看病”的流程。
1. 系统看病的第一步：命令手册不是字典，是诊断参考
1.1 手册的编号，其实是一张“分科室导诊图”
很多人打开man手册，第一反应是太长、看不懂，翻两页就退了。我最初也这样，后来发现问题是定位方式不对——手册根本不是按“从前往后读”设计的，它是按编号分类的，每个编号区域都可以看作一个科室。
Linux 手册一般分 9 个章节，常用的就前几个：
| 章节编号 | 内容类别 | 类比科室 |
|---|---|---|
| 1 | 用户命令 | 门诊大厅：患者能自己用的常规检查 |
| 2 | 系统调用 | 手术室：程序直接操作内核的底层接口 |
| 3 | C 库函数 | 检验科：编程时用的各类化验工具函数 |
| 4 | 设备与特殊文件 | 影像科：设备文件怎么查看和诊断 |
| 5 | 配置文件格式 | 病历模板：每个配置文件的字段布局 |
| 6 | 游戏 | 康复科，这个基本用不上 |
| 7 | 杂项与约定 | 会诊室：协议、编码等跨命令的通用规则 |
| 8 | 系统管理命令 | 院务办：只有 root 能开的特殊检查单 |
我平时查得最多的就是第 1、5、8 章。比如你写了个 Nginx 配置，改完不生效，这时候该查的不是nginx命令本身，而是man 5 nginx.conf——配置文件格式的“病历模板”在第五章。很多人没养成这个习惯，配置写错了只能对着报错瞎猜，完全不知道手册里有标准字段说明。
1.2 把排障拆成“诊断四步法”
干这一行久了，我发现系统排障和医生问诊的流程高度一致，可以压缩成四步：
- 主诉：用户说“网站打不开”“服务挂了”，这是症状，不是病因。
- 问诊：问清楚是什么时候开始、改了什么东西、有没有报错。
- 检查：用命令采集数据，相当于血常规、B超、CT。
- 处方：针对检查结果对症下药，改配置、调参数、重启服务。
这套流程里，命令手册承担的是第 3 步——帮你决定“做什么检查”。比方说，患者主诉“肚子疼”，你不能上来就做胃镜，而是先做血常规和腹部超声，排除明显问题再考虑侵入性检查。系统也一样，“系统变慢了”，不能直接重启服务，先看看 CPU、内存、磁盘有没有明显异常，再做进一步定位。
我刚入行时容易犯一个毛病：症状还没确诊，就急着执行自以为对的命令，结果经常把现场搞乱。后来养成习惯——不允许自己在一分钟内说出方案，先列检查单，把疑点数据凑齐再说。后面会用一个实际案例完整演示这套流程。
2. 分科坐诊：命令手册里的功能域按“科室”找
2.1 循环科：进程与资源管理命令
进程就像人体的循环系统，负责给各个“器官”输送计算资源。循环科的常用“检查设备”基本围绕进程状态展开：
ps：静态快照，看看当前有哪些进程活着。我习惯用ps -ef或ps aux，前者看进程父子关系清楚，后者看 CPU、内存占用直观。top/htop：动态心电图，持续观察哪个进程在跳。top的负载、内存、CPU 占用都是实时刷新的，系统慢下来的第一站基本是这里。kill：可以理解为“停药”——给某个失控进程发终止信号。但医用版要求严格：不是任何情况都上来就kill -9，大部分时候kill（默认 SIGTERM）就够，相当于让病人自然停止活动；kill -9（SIGKILL）是强制断电，可能会造成数据不一致，属于“急救电击”，要慎用。nice/renice：调节进程优先级，相当于给重症患者调床位，让关键进程优先拿到 CPU。
查手册时，我建议重点看man ps里的STANDARD FORMAT SPECIFIERS一段。大多数人只记ps aux和ps -ef两个格式，但真要看某些特殊字段（比如进程的 start time、session leader），字段说明就在那一段里，能节约大量查资料时间。
2.2 呼吸科：网络连接排查命令
网络像人体的呼吸系统，数据出入如果卡住，全身上下都会缺氧。这个科室的命令需要按“由外到内”的顺序查：
ping：先测“气道通不通”，判断对方主机是否可达，类似听诊器初检。注意ping通只能说明 ICMP 通了，不代表端口通。ss/netstat：看端口和连接状态，相当于胸片。ss -tulnp能列出监听端口及对应进程，排查“端口被占”“服务没监听”比netstat思路更清晰，性能也更好。curl/wget：模拟实际访问，等于做一次动脉造影，直接看返回码和响应时间。curl -v还能把握手全过程打出来，定位慢在哪一步。tcpdump/tshark：捕获数据包，这属于介入性检查，能看到载荷和协议细节，通常前几项查不出问题才动用。
常见场景：网站打不开，很多人先ping，发现能通，就没了方向。其实下一步就该ss -tulnp确认服务有没有监听，再curl -I看本地回环是否正常。检查顺序对了，问题范围一下子就能缩小一半。
2.3 消化科：文件、磁盘与存储命令
文件和磁盘就是系统的消化系统——负责吸收和保存数据。出问题时会表现为“读写卡顿”“磁盘满了”“找不到文件”。
df -h：检查整个磁盘的“胃容量”，看分区剩多少空间。注意df显示的已用百分比在 100% 时，系统往往已经出现异常。du -sh *：在目录里逐层查“谁占了这么多空间”，相当于胃镜检查，能定位到具体是大文件还是目录堆积。ls/find：查找文件，find可以按名字、时间、大小、权限过滤，比手动ls挨个翻目录高效得多。mount/umount：挂载和卸载存储设备，类似给消化系统外接营养管，磁盘没被识别时最常用。
我在处理“磁盘满了但服务还能跑”的情况时，有个常用组合：先df -h看整体，再du -sh /* 2>/dev/null | sort -hr | head -20看根目录下哪个目录最大，然后一路往下追。这套“由粗到细”的检查方式，和医生先看全片再聚焦病灶的思维完全一样。
2.4 检验科与会诊室：日志与内核消息
日志是系统的“病历本”，记录了每一次异常的主诉和检查结果。这个科室没有太多技巧，核心就两个字：会翻。
journalctl：Systemd 系统下最常用的日志查询命令，journalctl -u nginx看某个服务，journalctl -xe看最近一次错误上下文，journalctl --since "1 hour ago"按时间过滤，很接近医生查“最近一小时血压记录”。dmesg：看内核环路消息，硬件报错、磁盘 I/O 错误、驱动问题都会出现在这里。系统突然卡死、外设不识别，都是它出场的时候。grep：日志检索的基础工具，相当于在病历堆里搜关键词。配合tail -f实时跟踪，很像监护仪盯梢，新日志一出来立刻看到。awk/sed：在日志和文本流里做字段提取和编辑——检验科里负责“分离血清”的试管机。
新手最容易忽略的是journalctl的时间维度和级别过滤。一次服务崩溃，直接journalctl -u xxx --since "10 minutes ago" -p err，只取出错级别的日志，能少看几百行无关信息，排查速度快得不是一点半点。
我把这些“科室”汇总成一张速查表，放粘贴在手边很实用：
| 科室 | 对应系统模块 | 常用命令 | 典型场景 |
|---|---|---|---|
| 循环科 | 进程与资源 | ps、top、kill、nice | CPU 飙升、内存不足 |
| 呼吸科 | 网络连接 | ping、ss、curl、tcpdump | 网站打不开、端口不通 |
| 消化科 | 文件与存储 | df、du、find、mount | 磁盘满、找不到文件 |
| 检验科 | 日志与内核 | journalctl、dmesg、grep | 服务异常、内核报错 |
3. 一份真实的“病历”：网页加载慢的排查全过程
3.1 主诉与首诊检查
有一次线上应用突然变慢，用户反馈“页面一直转圈”。这是典型的主诉。假如我当时直接重启应用，症状可能短暂消失，但根因还在，过几天还会复发。于是我先按“诊断四步法”来。
第一步问诊：什么时候开始的？最近有没有发过版本？运维同事说，半小时前做过一次配置变更，之后应用就开始慢。这个线索非常关键——任何变更都是第一嫌疑人。
第二步首诊检查，我先画了一张“检查单”：
# 检查单 No.1：整体状态 uptime # 看负载：1分钟 / 5分钟 / 15分钟 free -h # 看内存：总量、已用、可用、swap df -h / # 看根分区剩余空间 ss -tulnp | head -30 # 看端口监听是否正常当时的输出里，负载平均值不算离谱，内存还有富余，端口都在监听。说明问题不在资源瓶颈这一层，至少不是“全身性的衰竭”。
3.2 深查：CT 扫描定位嫌疑进程
整体指标正常，但用户体感慢，那就往更细的方向查。第二张检查单聚焦 CPU 和进程：
# 检查单 No.2：聚焦检查 top -bn1 | head -20 # 一次性输出当前进程 CPU 占用排行 ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head -15top的结果里，有个 java 进程 CPU 占用达到 300% 以上，但平时它最多只有 80%。这个变化足够引起重视。我再看一眼它的启动命令，发现新变更多带了一个可疑的 JVM 参数，明显和半小时前的变更对得上。
这里要说一下，为什么不是直接kill进程，而是继续用ps和cat /proc/<pid>/cmdline去确认细节。因为 CPU 高只说明“心脏跳得快”，不一定代表“心脏病发”——可能是业务高峰正常跳动，也可能是死循环在空转。只有把进程的“病历”（启动参数、日志、依赖关系）凑齐，才能判断是不是真出了问题。
3.3 处方：对症下药与观察复诊
有了“可疑参数 + 高 CPU”两个铁证，我做了两件事：
- 先把进程的完整命令行用
tr '\0' ' ' < /proc/<pid>/cmdline导出来，发给同事确认这个参数是不是误配置。 - 同时查应用日志里有没有大量异常堆栈，确认这个进程是不是在做无意义的重复计算。
结果一确认，确实是误配的 JVM 参数触发了一个不必要的重试逻辑。回滚配置之后，CPU 在一分钟内降回正常水平，页面恢复秒开。
整个排查过程里，我没有用到任何冷门命令。真正解决问题的不是某个“神级命令”，而是检查顺序和判断逻辑。把一个宽泛的主诉“网站慢”，拆成“先看资源指标，再看进程明细，再对配置变更”，每步都用最基础的手册命令收集证据。这也是我说命令手册是“诊断参考”而不是“药方大全”的原因——命令只是检查器械，怎么判断、怎么决定下一步，靠的是临床思维。
3.4 复盘检查单
这次排查有效果，关键在于顺序没乱。我把检查单顺序固化成了这样：
# 1. 环境指标：负载 / 内存 / 磁盘 uptime; free -h; df -h # 2. 进程指标：谁在消耗资源 top -bn1 | head -20 # 3. 端口与服务：该听的是否在听 ss -tulnp | grep -E '80|443|8080' # 4. 日志与变更：结合代码发布记录看 journalctl -u <service> --since "30 min ago" -p err这套流程没有一条是与众不同的命令，但它能保证你在压力下不慌。很多时候排障慢，不是不会命令，而是上来就乱了检查节奏。
4. 处方药警告：手册里容易误伤的猛药
4.1 高风险命令的风险对照表
医生开处方前会权衡药理和副作用，命令也一样。有些命令一旦用错，后果不是“服务重启”那么简单，而是数据丢失、系统无法启动。我把它们列成一张“处方药警告表”：
| 风险命令 | 常规用途 | 潜在副作用 | 建议 |
|---|---|---|---|
rm -rf | 递归强制删除 | 误删文件、目录，不可恢复 | 执行前先ls确认路径，必要时加--preserve-root |
mkfs | 格式化文件系统 | 格式化错分区，数据清空 | 用lsblk核对设备名，绝不在挂载的救命分区上实验 |
dd | 块级复制/写入 | 写错of设备会整盘毁掉 | 先lsblk确认目标设备，用小块测试写入 |
kill -9 | 强制终止进程 | 进程无法优雅退出，数据可能未落盘 | 先kill（SIGTERM），观察 3 秒再考虑-9 |
chmod -R 777 | 批量放开权限 | 权限体系损毁，可能被恶意利用 | 尽量用最小权限，按chown/ACL 分配 |
你可能觉得这个表太基础了，但我确实见过不止一个运维新手在这些命令上栽跟头。有一次同事在测试环境想清空某个临时目录，执行前少打了一个字母，结果把上一个目录给清了——恰巧那是项目源码目录。当时没有版本控制工具兜底，情绪直接失控。这不是技术问题，是无视“用药安全”的必然结果。
4.2 我踩过的 rm 大坑
刚工作时我用过一个自认为万无一失的写法：
rm -rf /server/backup/*.log # 想法：只删除日志文件结果执行完才发现，当时的当前目录根本不是/server/backup，而变量的值又恰好为空，展开后命令变成了：
rm -rf /*.log虽然因为通配符没有匹配到根目录下的日志文件，没有造成灾难，但那一瞬间我的冷汗是真的冒出来了。后来我给自己定了三条“安全用药”纪律：
- 执行有风险的命令前，先进入目标目录，用
pwd和ls看清当前环境。 - 变量路径必须加引号，并且先
echo打印展开后的真实命令。 - 能用
find带-delete的场景，也别图省事直接rm -rf，宁可多写点。
这三条直到今天我还贴在自己的工作笔记第一页。
4.3 把“用药安全”写进操作习惯
除了上面这三条，我平时还有一套更完整的自我约束：
- 高风险操作前先打快照：如果是云服务器，先做快照或备份；如果是本地，至少把要动的文件
tar一下。 - 写脚本时一律用绝对路径，并且加
set -u防止变量未定义时变成空字符串。 - 任何带有“强制、批量、递归”含义的操作，先看一遍
man里EXAMPLES段落，确认选项含义后再执行。手册里 BUGS 段落很多人都没注意过，但我恰恰认为那是“副作用说明”，不读不行。
这些习惯看上去没技术含量，但排障现场最容易翻车的不是不会诊断，而是乱用药。诊断错了不致命，开错药才致命。
5. 复诊与随访：把命令手册变成自己的知识库
5.1 先学会怎么“查病名”：man -k 与 whatis
回到最开始的问题：怎么高效使用命令手册？我有一个强烈的建议——少背命令，多学“查命令”的能力。这对应两个被低估的命令：
whatis <关键词>：一句话告诉你是干什么的，相当于病历首页上的诊断结论。man -k <关键词>（等价于apropos）：在手册全文中搜索相关条目，相当于按症状关键词搜所有可能疾病。
举个例子。你记不清“想查看系统启动时间”用什么命令，不需要问人，直接：
man -k boot | head -20输出里会列出systemd-analyze、uptime、last等和 boot 相关的条目。这时候再看man uptime确认用法，两条命令就解决问题。这种“搜病名—查药方—确认剂量”三步法，比死记硬背高无数倍。
5.2 给自己建一个“病历本”
我会建议每个运维、开发都把常用排查命令沉淀成自己的“病历本”。不是抄网上的命令大全，而是记录“什么症状 + 用什么命令 + 看到了什么结果”的真实案例。我自己是用一个 Markdown 文件维护的，每条大致长这样：
## 症状：服务端口起不来 - 检查1：ss -tulnp | grep <port> # 看是否被占用 - 检查2：journalctl -u <service> --since today -p err # 看报错 - 常见根因：端口冲突 / 配置语法错误 / 权限不足这样做的好处是，当你下次再遇到类似问题时，不需要重新做整套鉴别诊断，直接对照自己的病历本就能走到熟悉的路线上。工程和医学一样，经验的价值在于反复验证和积累。
5.3 面向面试的高频考点怎么组织
很多人为了准备 Linux 面试题拼命背命令，其实更高效的办法是按场景组织。面试官通常不是考你背了几个参数，而是考你排障思路。把高频问题分三类：
- 系统状态类：CPU 满、内存耗尽、磁盘 IO 高，对应
top、free、iostat、vmstat。 - 网络排查类：端口不通、连接数高、丢包，对应
ss、netstat、tcpdump、ping。 - 权限与文件类：权限不足、文件被删、句柄耗尽，对应
ls -l、chmod、ulimit、lsof。
每一类我建议都用“症状到命令”的方式过，而不是从命令到参数地背。比如问“磁盘空间没满但写不了文件”，你要能想到可能是 inode 耗尽，然后自然联想到df -i。这种命令知识才真正属于你。
从“医疗视角”看手册，最有价值的一点就是：手册从来不是命令堆砌的天书，它是按人体组织形态分好的科室指南。你的系统哪里疼，就该去哪个科室翻哪一章。把“先诊断、后用药”变成肌肉记忆，比记住一百条命令都管用。这期讲的是怎么读懂和使用手册这本地图，下一期我准备接着聊“医疗视角下的 Linux - 03”里系统日志和进程这几张关键“化验单”怎么解读，到时可以拿几个真实故障案例继续顺着检查单往下走。
