Linux命令场景化手册：从基础到故障排查实战

先把话放这儿：如果你只是把 Linux 命令当成“背单词”，那你大概率会在三个月后忘掉一半，半年后彻底回到图形界面。这套《Linux 网络操作系统常用命令手册》不是又一份命令清单，而是把命令按“运维场景 + 排查链路”重新组织过的实操笔记。它解决的不只是“某个命令怎么用”，而是“服务器出问题了我该按什么顺序敲哪些命令”以及“面试官问 Linux 时到底在问什么”。适合刚接触 Linux 的初学者、准备转行运维的开发、以及日常需要登录服务器处理问题的后端和测试同学。我把这些年踩过的坑、生产环境里验证过的手段，全部揉进这篇手册里，按我的习惯来写，不按教科书排版。

这么多年用下来，我最大的感受是：Linux 命令的价值不在单个命令本身，而在组合。单看grep、awk、sort谁都会，但把它们用管道串起来，一条命令替你在几百 GB 日志里把故障原因揪出来，那才是真正的手册意义。所以这篇内容我会刻意强化“为什么这么用”和“组合起来怎么用”，而不是简单罗列参数。

1. 命令体系与上手思路

1.1 为什么 Linux 命令手册要先讲体系，不先讲命令

先说一个很多人忽略的事：Linux 命令不是孤立存在的，它们背后是一套统一的哲学。文件是文件，设备是文件，网络连接是文件，进程信息也是文件——只不过它们出现在/dev、/proc、/sys这些特殊目录里。理解“一切皆文件”之后，你再看很多命令会觉得豁然开朗，比如查看 CPU 信息不用装任何工具，直接cat /proc/cpuinfo；查看内核参数不用翻文档，直接sysctl -a或者读/proc/sys下的文件。这个思路比记住一百个命令参数重要得多。

我自己的建议是：不要按命令字母顺序学，也不要去背所谓“最全命令大全”。那种东西看一遍除了击退学习热情，没有别的效果。更好用的路径是先建立三个基本盘——第一，路径与文件概念，搞清楚当前目录、绝对路径、相对路径、隐藏文件；第二，帮助系统怎么用，man、info、--help是三个层级的查询手段；第三，管道和重定向思维，这是把简单命令变成强大工具的分水岭。三块地基打好之后，任何新命令对你来说都只是“又多了一个积木”。

顺着这个体系看 Linux 网络操作系统里的“网络”二字，很多人的理解也有偏差。这里说的网络不是指 Linux 只能用来做路由器或交换机，而是指 Linux 作为服务器操作系统，天生要面对网络服务、端口监听、连接状态、防火墙规则这些问题。所以后面的章节里，我会把网络排查单独拉出来重点讲，因为这是日常工作里最容易让人挠头的地方。

1.2 三层帮助体系：先学会如何学会

所有命令的第一课不是参数，而是“怎么查帮助”。我在带新人时反复强调：Linux 里没有哪个老师能记住所有参数，高手和新手的差别就在于谁更会查、查得更快。

第一层是命令 -h或命令 --help，这种简短帮助适合快速确认某个参数拼写。第二层是man 命令，完整手册页，里面不仅有参数说明，还有退出状态、示例、环境变量、相关文件等细节。第三层是/usr/share/doc/下对应软件的文档目录，适合查配置示例和变更记录。比如你写 systemd 服务时不确定某个指令，man systemd.service里的说明比网上大部分博客都准确。

这层内容之所以重要，是因为它直接决定了你后面所有学习效率。我见过太多人卡在“这个命令怎么没有--help”上，其实只是没装 man 页，或者命令是 shell 内建命令。比如cd、export、umask这类 shell 内建功能，要查它们的帮助得用help cd，而不是man cd。这个细节在面试里偶尔也会被当作测试点，实际使用中更是高频场景。

1.3 管道、重定向与通配符：把命令串成流水线

管道是 Linux 命令组合的粘合剂。它做的事情很简单：把前面命令的标准输出接到后面命令的标准输入。但就是这一个“简单”设计，让命令行变成了生产线。举例来说，下面这条命令是我排查日志时几乎每天都要用到的套路：

cat app.log | grep "ERROR" | wc -l

先把日志内容输出，再从里面筛出包含 ERROR 的行，最后统计有多少行。三个命令各干一件事，通过管道串联成一个统计操作。如果不用管道，你得先把grep结果存成临时文件，再用wc -l读文件，麻烦得多，还会在磁盘上留下垃圾文件。

重定向则是把命令的输出导向到文件或者设备。>覆盖写，>>追加写，2>处理错误输出。这里有一个经常被新手忽略的坑：command > file 2>&1和command 2>&1 > file执行效果不同，因为重定向的绑定顺序是从左往右的。我建议直接记> file 2>&1这种写法，意思是“标准输出先重定向到文件，错误输出再复制到标准输出当前指向的位置”，这样日志和错误就能一起进文件。

再补一个容易被面试问到的细节：管道只传递标准输出，不传递标准错误。如果前面命令的报错信息被你漏掉了，多半是因为错误走的是标准错误通道。解决方法是command 2>&1 | grep xxx，先把错误并到标准输出，再交给管道。这个坑我在新手期踩过一次，排查了半天以为是程序没输出，其实输出都到屏幕上错了。

通配符这方面，*、?、[abc]配合 ls、find、rm 使用很方便，但要注意一个原则：能不用rm -rf加通配符就不用，尤其是你对目录结构还不够熟的时候。我后面会在常见问题里详细讲这个事故高发点。

2. 文件与内容操作实战

2.1 文件目录管理：ls、cd、cp、mv、rm 的正确打开方式

文件管理是 Linux 的入口，但很多人的用法都停留在“会用”而不是“用得对”。先说ls，它的大多数参数你都应该掌握，但最实用的是-lh（人类可读的详情列表）和-lt（按时间排序）。ls -lt | head能直接看到目录里最近被改动的文件，排查“刚改了哪个配置”时特别好用。

cp命令要重点学会cp -r递归复制目录，以及cp -a保留权限和时间戳。为什么强调保留权限？因为你从一台服务器复制一个目录到另一台时，如果权限全乱掉，后面服务起不来，你都不知道是什么原因。用-a就等于把文件的属性原封不动带过去，省去后续手动chmod的麻烦。

rm是全手册里最危险命令，没有之一。我的建议是养成三个习惯：第一，进入一个新目录后先pwd确认位置；第二，批量删除前先ls看一下要匹配的文件到底是什么；第三，重要目录里的删除操作，用mv移到 /tmp 而不是直接rm，确认没问题再清。简单说就是一个原则：删之前先看，看完再删；能暂存就不直接删。生产环境里无数事故都是多敲了一个空格或者多写了一个星号造成的。

mv的实际使用中有个常被忽略的点：同一文件系统内的 mv 是改个名字的事，瞬间完成；跨文件系统的 mv 是先复制再删除。如果你在大文件迁移时发现 mv 卡住，多半是跨了分区，这时候可以考虑改用rsync并保留进度，中断后还能续传。

2.2 文本查看与检索：cat、less、tail、grep 组合烤

查看小文件直接cat，大文件必须用less。less比more强的地方在于可以上下翻页、直接输入/搜索、按n跳下一个匹配项，甚至可以按v进入 vim 编辑模式。我处理几百兆日志时基本都是less起手，先找到问题范围，再用tail精确抓取，而不是一上来就cat一整个文件把终端撑爆。

tail最有名的用法是tail -f，实时追踪文件新增内容。调试时开两个终端，一个跑服务，一个tail -f /var/log/syslog，效果非常好。加-n 100可以从倒数第 100 行开始看，避免启动瞬间的历史日志刷屏。这里有个小技巧：tail -F（大写 F）比tail -f更抗文件被轮转（logrotate 改名后新建文件），生产环境要跟日志用大写 F。

grep是文本检索之王。基础用法是grep "关键词" 文件名，但你要会用-r（递归目录）、-i（忽略大小写）、-v（反向匹配）、-A/-B/-C（显示匹配行前后几行）。排查程序崩溃时，grep -C 5 "Exception" error.log能把异常周围上下文一次拉出来，比单独筛选有效得多。

再配合head和wc：head -5看前几行确认格式，wc -l统计行数。有一次我们处理导出任务，怀疑数据被截断，直接wc -l source.csv对比目标库记录数，一分钟就确认了问题出在导出端而不是入库端。这种组合比任何监控面板都直接。

2.3 文本处理三剑客：grep、sed、awk 的组合套路

这三者每次都会被放在一起讲，因为真实场景里它们经常合作。基础分工：grep 负责筛选行，sed 负责按行编辑替换，awk 负责按列取数据并做统计。举例，你想要日志里某个接口的 5xx 数量：

grep "GET /api/order" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

这条组合的动作是：先把包含接口路径的日志行筛出来，再用 awk 取第 9 列（HTTP 状态码），然后 sort 排序让相同状态码聚在一起，uniq -c 统计每个码出现的次数，最后 sort -rn 按数字倒序排列。结果一眼就能看出 200 最多还是 500 太多，不用写脚本，不用开 Excel。

sed经典场景是批量替换配置文件。sed -i 's/old/new/g' file.conf就能原地改文件。但要小心-i直接改原文件，出错了不好回滚。稳妥的习惯是先用不带-i的命令输出到屏幕预览结果，再正式修改；或者cp file.conf file.conf.bak先备份。生产环境任何批量操作之前先备份，这句话值得打印出来贴屏幕边上。

awk不止能取列，还能做条件判断和累计。比如从日志里统计某接口 P99 耗时虽然复杂了点，但简单场景下awk '$16 > 3'能直接筛出耗时时长大于 3 秒的请求。还有awk里NR表示当前行号，NF表示当前行字段数，这两个变量在调试字段结构不均的数据时非常管用。我常说 awk 是个被严重低估的“微型编程语言”，你不需要完整学它，但掌握取列、判断、累计三招，已经能覆盖大部分日志分析需求。

3. 系统、权限与服务管理

3.1 用户与权限模型：看懂 drwxr-xr-x 才不算白用 Linux

权限问题几乎是新人接触 Linux 的第一道坎，也是面试必问。ls -l输出的第一列，比如-rw-r--r--，一共十个字符，第一个字符表示文件类型（-普通文件，d目录，l软链接），后面九个字符每三个一组，分别代表拥有者、所属组、其他人的读（r）、写（w）、执行（x）权限。

数字表示法也很简单：r=4，w=2，x=1，加总起来就是权限值。比如chmod 755 file，意思是拥有者 rwx（7），组和其他人 rx（5）。这个数字不是随便记的，它是二进制位的换算，理解了之后你就不会再背表格，而是会算。目录的执行权限尤其容易被忽略：如果目录没有 x 权限，你即便有 r 权限也进不去这个目录。这是很多“我 ls 能看到名字但 cd 进不去”问题的根源。

用户管理方面，日常用到最多的是useradd创建用户、passwd设密码、usermod -aG group user把用户加入附加组。注意-aG一定要带-a，否则会把用户从原来的附加组里剔除。这个坑我踩过一次，加完发现用户 docker 权限没了，排查半天才想起来usermod -G覆盖了原有组列表。

sudo权限配置在/etc/sudoers，但是必须用visudo打开修改，因为 visudo 会做语法校验，防止你写错导致 sudo 系统崩掉。给用户授权时，尽量精确到可以执行的命令而不直接给ALL=(ALL:ALL) ALL。比如user ALL=(ALL) NOPASSWD: /usr/bin/systemctl让这个用户只可以免密管理系统服务，这对特定运维角色很实用。

3.2 进程与服务：ps、top、systemctl 的排查顺序

进程管理里，先记住一个排查固定链路：先看负载，再找进程，再看日志。开机服务器变慢，第一件事是uptime看 load average 三个数；如果持续比 CPU 核数高，说明存在过载或阻塞。然后再看top，按P键按 CPU 排序，按M键按内存排序，找到异常进程的 PID。最后用ps -fp PID看它的启动命令和参数，就能判断是不是哪个服务没配好导致吃资源。

ps命令本身的参数风格容易把人绕晕，因为有的组合是 BSD 风格（不带横线），有的带横线。我常用的组合是ps -ef全格式显示所有进程，加上grep就能筛目标服务：ps -ef | grep java。如果你想知道某个进程到底监听了哪些端口，用ss -tnlp | grep PID会更直接，输出的最后一列会带进程名和 PID。

systemd 已经是目前主流发行版的默认服务管理器。必须掌握的指令是：systemctl start/stop/restart/status 服务名，以及systemctl enable设置开机自启。systemctl enable --now可以一步到位“启用并立刻启动”，这个组合用法非常省事。排查服务起不来时，先systemctl status xxx看状态，再journalctl -u xxx -n 50看最近日志，大多数失败原因都能定位。

服务管理方面还有个容易出错的地方：改完配置文件，服务不会自动重载。很多人在/etc/nginx/nginx.conf改完就直接看效果，发现没变，其实还要nginx -t先检查配置语法，然后systemctl reload nginx平滑重载。后端程序也一样，Java 类服务通常需要重启进程才认新配置。生产环境操作前记得分清楚 reload（平滑，不断连接）和 restart（强制重启，可能短时间断服务）。

3.3 系统信息诊断：uname、free、df 的正确解读

系统信息类命令单独拎出来讲一节，是因为它们每一个都对应一类故障信号。uname -a查看内核版本与架构信息，排查驱动不兼容、内核模块加载失败时必用。free -h查看内存使用，关键要看的是 available 这一列而不是 free 那列，因为 Linux 会尽量把空闲内存用作缓存，free 很小不代表内存不足，available 才是真正可用的内存量。

df -h查看磁盘剩余空间，能发现“磁盘满”这类最常见的故障源头。注意df显示的是文件系统已使用块，而不是 inode 使用情况。有时候df显示还有空间，但报错无法创建文件，那大概率是 inode 耗尽了，用df -i查看 inode 使用率。这类问题常见于小文件极多的缓存目录，比如tmp或跑爬虫程序的输出目录。

dmesg也是排查利器。内核打印的硬件信息、磁盘报错、OOM（内存溢出）都会出现在dmesg输出里，配合tail可以快速定位是不是因为内存不足触发了内核杀进程。有一次应用突然挂了，top 看不出直接原因，执行dmesg -T | tail -20，发现一堆“Out of memory: Kill process”记录，立刻确认是内存不足导致 OOM Killer 动手了。这类问题光看应用日志根本找不到原因，必须去内核日志里翻。

4. 网络排查与日志分析

4.1 从 ping 到 curl：网络连通性排查的标准步骤

网络排查就像剥洋葱，必须一层一层来。我的固定打法：先ping 目标IP确认三层通不通，再telnet 目标IP 端口或nc -vz 目标IP 端口确认端口通不通，最后才用curl验证整个 HTTP/DNS 链路。很多人一上来就 curl 一个域名，失败后就怀疑服务挂了，其实是 DNS 解析或出口网络的问题，顺序完全不对。

ping能通只代表 ICMP 通，不代表业务通。比如防火墙可能放行 ICMP 但拦截 TCP 端口，所以“能 ping 通但连不上数据库”是完全正常的现象。这时候用telnet IP 3306就能快速确认 MySQL 端口是否可达，比 ping 更有意义。新版本 Linux 可能没有 telnet 客户端，可以用nc，写法是nc -vz -w 2 192.168.1.10 3306。

ss命令查看本机监听与连接状态，替代老旧的netstat。最常用的是ss -tnlp，显示所有 TCP 监听端口和对应进程；ss -tn state established | wc -l统计当前连接数。排查端口被占用时，ss -ltnp | grep 8080可以立刻告诉你 PID，再ps -fp PID看是谁，整个过程不到 10 秒。

如果网络延迟异常，mtr比traceroute更直观，它会持续检测每跳节点的丢包率。用它排查“访问慢但没断”的问题时，如果发现某一跳持续丢包，基本可以锁定瓶颈。生产服务器上如果没有 mtr，可以临时traceroute -n跑一次，看看路径和延迟分布。记住一个原则：先链路后端口，先端口后应用，别跳过层。

4.2 curl 详解：接口调试与故障复现的瑞士军刀

curl 恐怕是所有 Linux 命令里最被常用的网络工具。绝大多数“服务连不上”的排查，最后都会落到 curl 上。最常见的写法是curl -v http://localhost:8080/api/health，-v会输出完整的握手、请求头、响应头、SSL 证书信息。我收到一个 HTTP 调用失败的反馈时，第一件事就是在服务器本地跑一条带-v的 curl，能快速区分问题出在 DNS、TCP、TLS 还是应用层。

curl 还常用作 HTTP 接口测试。-X POST指定方法，-H加请求头，-d传数据，例如：

curl -X POST -H "Content-Type: application/json" -d '{"name":"test"}' http://127.0.0.1:8080/api/user

如果只想看响应码和耗时，加-w：curl -o /dev/null -s -w "HTTP_CODE:%{http_code} TIME:%{time_total}s" URL。这片段把响应体丢弃、只打印状态码和总耗时，非常适合快速评估一个接口的可用性。

curl 下载文件也很常用，curl -O保留远程文件名，curl -L跟随 301/302 跳转。很多开源软件的安装脚本会用到curl -fsSL，-f表示出错时不输出 HTML 错误页，-sSL里-s是静默、-S让静默时仍显示错误、-L跟随跳转。这四个参数组合可以说是下载远程脚本的标准姿势。

4.3 日志中心：journalctl、dmesg、tail -F 的使用分工

systemd 时代，日志管理已经统一到journalctl。查服务日志的固定命令是journalctl -u 服务名，按时间过滤用--since "1 hour ago"或者--since today。跟踪实时日志用journalctl -u 服务名 -f。网上不少老教程还在让你去/var/log/messages翻，但新版发行版上 systemd 服务日志优先用 journalctl。当然，应用把自己的日志写进/var/log/app/xxx.log的情况仍然常见，所以两个方向都要会。

dmesg前面提过是查内核日志，这里再强调一个场景：硬盘报错。磁盘出现坏道、I/O 错误时，dmesg -T | grep -i error很可能直接显示blk_update_request： I/O error之类的记录。这类问题如果你只查应用日志，根本看不到；但通过 dmesg 能提前发现磁盘隐患，趁数据还能读出来赶紧备份。服务器硬件诊断这块，dmesg 是最快入口。

日志分析要记住一个效率原则：先缩小范围，再深入细节。范围缩小靠时间关键词、服务名、错误级别，比如journalctl -u nginx --since "10 minutes ago" | grep "error"先看最近十分钟的错误。然后沿着报错关键词再往外展，查看上下文。盲目从头看一个大文件很容易被无关信息淹没，排查效率很低。我习惯的做法是先tail -100看最近的报错长什么样，再反向去日志里搜出现次数和规律，而不是顺着时间一路往下读。

4.4 防火墙与端口：firewalld/ufw 的常用操作

CentOS/RHEL 系默认用 firewalld，Ubuntu 上常见 ufw。很多人开发环境不碰防火墙，一到生产环境连不上服务，排查一圈发现是防火墙挡了端口。先教的命令是查看当前放行规则：firewall-cmd --list-all。放行端口：firewall-cmd --permanent --add-port=8080/tcp，然后firewall-cmd --reload重载生效。如果嫌永久参数麻烦，可以不加--permanent临时放行，但服务器重启后配置会丢。

ufw 的写法类似：ufw allow 8080/tcp，ufw status numbered查看规则并带序号，删规则用ufw delete 序号。ufw 默认启用了的话，ufw enable要小心，因为一旦启用默认策略是拒绝所有入站连接，如果在远程服务器上操作且没放行 SSH 端口，那你就把自己关在门外了。这是个奉劝各位刻在脑子里的教训，远程操作防火墙前，先确认放行了 SSH 端口，否则等着让机房同事帮你物理重启。

端口占用排查里还有个命令容易被忽略：lsof -i :8080。它能列出占用 8080 端口的进程，包括 PID 和进程名。和ss相比，lsof 的输出更直观，但有些系统需要安装。没有一个命令是万能的，ss、lsof、netstat 三个互相补充，生产环境里至少熟练两个。

5. 磁盘、软件包与文件传输

5.1 磁盘空间排查：df、du、lsof 的实战组合

这是运维事故最高发的场景，没有之一。磁盘满了一下子可能出现各种奇怪问题：服务写不了日志、数据库报只读、临时文件创建失败。排查步骤固定：df -h先看整体使用率，找到使用率接近 100% 的挂载点；然后进到对应目录，用du -sh *逐级查看各子目录占用大小；最后定位到大文件或者疯狂增长的日志目录。

du的参数建议直接用du -sh 目录（只看目录总大小）或者du -h --max-depth=1（看当前目录下一级各子目录大小）。有一次我排查一个 60G 的磁盘占用，用du -h --max-depth=1 /发现/var占了 45G，再跟进/var/log看到一个达到 30G 的 nginx access.log，问题瞬间清晰。整个过程不到两分钟，而如果靠肉眼翻文件列表，可能得翻半天。

还有一类情况：df显示磁盘 100%，但你du发现所有文件加起来远没到 100%。这时候八成是因为已删除的文件仍然被某个进程占用。Linux 下删除文件，如果进程还持有文件句柄，空间不会真正释放。解决方式是lsof +L1 | grep deleted，找到正在占用已删除文件的进程，重启它或让它释放句柄，磁盘空间才会回来。这类问题在日志轮转不彻底的服务上太常见了，所以 lsof 一定要会。

大文件查找用find / -type f -size +1G，可以在根目录全盘扫描大于 1G 的文件。生产环境全盘 find 可能有点慢，可以限定在/var、/home、/opt这些重点目录。另外配合find ... -mtime +30按修改时间删旧归档文件，也是日常清理的重要手段。

5.2 软件包管理：apt、dnf/yum、源码安装的取舍

Debian/Ubuntu 系用 apt，RHEL/CentOS 系用 dnf 或 yum，日常逻辑一致：更新索引、安装包、卸载包、查包。apt update先更新软件源索引，然后apt install 包名。搜索包用apt search 包名，查看已装包dpkg -l | grep 包名。dnf 对应的是dnf search和rpm -qa，RHEL8 之后的 dnf 用法和 yum 基本兼容，yum 只是 dnf 的软链接。

源码安装当前主要出现在两种场景：官方仓库版本太老，或者需要自定义编译参数。通用套路是./configure --prefix=/usr/local/xxx && make && make install。我建议除非必要，否则优先用系统仓库或者官方二进制包，因为源码安装会带来后续升级困难、依赖零散、卸载不干净的问题。前几年为了装新版 redis，源码安装在 /usr/local 下，后来系统仓库更新了 redis，结果两套版本在环境变量里打架，排查了一个下午才发现是 PATH 顺序导致调错二进制。

tar 包安装也有讲究。tar -xzf解压到当前目录，tar -C /opt指定目录。看到.tar.gz，-xzf组合基本通用；.tar.bz2用-xjf；.tar.xz用-xJf。这几个小差别面试偶尔会问，实际操作中tar -tf 包名先列出文件内容，确认包内顶层目录结构，永远值得先做一次，免得解压后文件散落一地。

5.3 文件传输：scp、rsync 的典型差异

服务器之间的文件传输最常见的两个工具是 scp 和 rsync。scp 胜在简单，一条命令全量复制，适合临时传单个文件。scp 本地文件 user@host:/远程路径或者反向scp user@host:/远程路径 本地路径，注意本地和远程的顺序和cp一致，都是“源在前，目标在后”。

rsync 的优势在于增量同步、断点续传、保留文件属性。日常同步目录的固定写法：rsync -avz --progress /本地目录/ user@host:/远程目录/。这里有个细节是目录末尾的斜杠：源目录带斜杠表示复制目录内的内容到目标目录，不带斜杠表示把目录本身也带过去。这个行为差异很容易导致目录层级比预期多一层或少一层，建议自己试验一次就会有肌肉记忆。

rsync 跨服务器时如果走默认 SSH 通道，压缩和加密是同时进行的。内网大规模同步时可以考虑--partial保留部分传输文件，中断后重跑会自动续传。如果目录非常大，第一次同步时间很长，可以先rsync -avz --dry-run做一次试跑，看看到底会传输多少内容和多少大小，避免一把梭直接开跑，结果传输几个 TB 导致网络被打满。

6. 高频面试考点与真实故障排查

6.1 面试官真正想考的那些点

Linux 相关面试，考来考去其实就那几个核心点。软链接和硬链接是重灾区。软链接就像 Windows 的快捷方式，存的是路径字符串，原文件删了链接就失效；硬链接直接指向同一个 inode，删除任一链接名，文件数据还在，除非所有链接都被删。创建方式为ln -s 源 链接名（软）和ln 源 链接名（硬，不能跨文件系统）。面试官追问“为什么硬链接不能跨文件系统”，因为 inode 编号是每个文件系统独立的，跨文件系统关联不到同一个 inode。

Linux 目录结构也是必考。能说出/etc放配置、/var/log放日志、/proc是内核状态虚拟文件系统、/tmp临时目录、/usr/local用户安装软件位置，基本就算过关。进阶考点包括：/etc/passwd存储用户信息，/etc/shadow存储密码哈希，所以密码字段在 passwd 里显示的是 x 而不是明文。

还有一类场景题：“端口被占用了怎么办”。标准答案其实就是上面说的链路：ss -ltnp | grep 端口找 PID，ps -fp PID看进程，确认不是自己服务后，要么换端口要么停掉占用进程。场景题里给出的是“Java 进程占用 8080 但无法 kill”，进一步考察定位服务来源的方法，也许是pwdx PID看进程工作目录，或者ls -l /proc/PID/cwd找到对应的应用目录。

6.2 一次完整的“服务突然变慢”排查实录

讲一个我印象深刻的现场，帮你把前面内容串起来。有次线上服务突然响应变慢，监控面板显示平均延迟从 200ms 涨到 3 秒。我先uptime，看 load average 在 15 左右，而机器是 8 核，说明系统负载明显过高。再top按 CPU 排序，看到一个 java 进程 CPU 打到 700%。接下来该进应用日志查具体原因了。

我看ss -tnlp | grep 8080确认就是那个 java 进程，然后进日志目录tail -F app.log，发现大量线程在等待数据库连接超时。接着查数据库侧，df -h显示数据盘 100%，du -sh /var/lib/mysql确认数据目录异常大，再ls -lh /var/lib/mysql看到几个超大 binlog 文件。删除过期 binlog 后，磁盘恢复，数据库连接恢复，应用延迟回到 200ms。

这个例子里，没有一道命令是在“秀技巧”，全部是最常见命令的组合：uptime看负载、top找进程、ss确认端口、tail看日志、df查磁盘。但顺序对了，5 分钟就能定位根因。反过来说，如果一开始直接进应用日志抠半天异常，很可能由于磁盘满导致日志刷不出来而陷入死角。排查问题的本质不是知道多少命令，而是知道按照什么顺序用已知命令。

6.3 提权相关的安全边界说明

这里必须说清楚一个边界：日常运维中凡是涉及sudo、su、文件属主切换的都属于正常的权限管理操作，比如用sudo systemctl restart nginx、su - deploy切换到应用账号部署。但是任何绕过授权机制、在未授权环境下提升权限的行为都是严格禁止的，也绝不建议你去研究或尝试。Linux 系统安全的前提是权限边界清晰，把心思放在了解sudo权限控制、文件权限模型、进程隔离上，才是正确的方向。安全测试类发行版里的大量工具都带着明确的授权要求，不是给你在生产环境乱用的。

公共服务器安全还涉及sshd配置。/etc/ssh/sshd_config里建议关闭PermitRootLogin，使用密钥认证而不仅是密码登录，并修改默认端口或至少配合防火墙限制来源 IP。这些都是合规、必要的加固手段，与权限提升完全是两回事。运维同学的重点是理解最小权限原则，而不是剑走偏锋。

7. 常见问题与快速速查表

7.1 最容易踩的五个坑

第一个坑是rm -rf与变量为空。正确姿势是删之前先echo $变量名确认非空，比如rm -rf ${LOG_DIR}/old/*里 LOG_DIR 得先确认定义了，否则可能变成rm -rf /old/*甚至更糟。第二个坑是分区满但du看不到占用，用lsof +L1 | grep deleted处理。第三个坑是防火墙把自己锁在外面，远程操作防火墙之前先放行 SSH 端口。第四个坑是crontab里命令写绝对路径，因为 cron 环境变量极简，PATH里通常没有/usr/local/bin，脚本里调命令尽量全路径，或者脚本开头先export PATH=/usr/local/bin:/usr/bin:/bin。第五个坑是改了配置文件没有 reload/reload 失败，改完nginx -t等服务自带的配置检测命令，确认无误再 reload。

7.2 常用命令速查表

这张表不适合背，适合放在手边当字典查。真正用得多，自然记得住；查得勤也不丢人，我用 Linux 快十年，偶尔还得man一下冷门参数。命令手册存在的意义从来不是考验记忆力，而是帮你用最短的时间把事情做对。

7.3 怎么把这套手册内化成自己的技能

我的经验是三个字：造场景。不要在服务器上只是“看着玩”，给自己布置明确的任务——比如在一台全新 Ubuntu 上从零部署一个 Nginx 静态站点并配置 HTTPS、写一个每天凌晨压缩备份日志的 cron 脚本、在磁盘快满时徒手找到罪魁祸首。这种任务式学习每一趟下来，上面提到的命令基本都能摸一遍。

还有一条捷径：把常用复杂命令写成小脚本存到/usr/local/bin或者~/bin。比如我把我最常用的日志分析命令封装成脚本logstat，参数只传日志路径和关键词，输出最近一小时错误数量、TOP5 报错内容。这样以后用起来不会忘，因为命令是你自己设计的，逻辑记住了。新人容易陷入“搜集大量命令大全”的收藏陷阱，收藏夹常年吃灰，不如静下心把十条命令练到条件反射。

我自己到现在仍保持一个习惯：每处理完一次故障，就把排查的过程用注释写在个人笔记里，记录触发命令、输出特征和最终根因。几个月后回看，这些笔记构成了我的个人命令手册，比任何公开手册都顺手。所以这篇内容你不需要全记，只需要把它当成起点，跑几遍真实任务，逐步积累你自己的版本。真正的“手册”永远是你实战之后长在手上的那一份。

最后分享一个小细节。我用grep排查问题的时候，几乎不会直接输裸关键词，而是配合-E用正则一次匹配多个模式，比如grep -E "ERROR|Exception|timeout" app.log。这样第一轮筛出的内容信息量大，第二轮再精确展开。命令行不是玄学，它只是把“先看哪、再看哪”的思路用最快速度落地的工具。把思路理顺了，手自然就跟上了。