Linux常用命令系统学习：从Shell管道到服务器故障排查实战

刚接手一台服务器时，最尴尬的场面往往不是权限报错，而是一行命令敲下去，终端只回一个闪烁的光标——你知道要查日志、要看磁盘、要重启服务，但不知道从哪条命令开始。于是切回浏览器，从收藏夹里翻出那篇“Linux 常用命令大全”，对着 100 多条命令列表从头扫，最后只用了 cd 和 ls。

这几乎是所有零基础学 Linux 的人都会经历的一轮。问题不在于命令记不记得住，而在于大多数命令清单是按字母顺序堆出来的，没有告诉你每条命令在真实工作流里卡在哪个环节。df 和 du 放在一起你看不出区别，kill -15 和 kill -9 挨着排版你也不会知道哪个先按；等真遇到磁盘打满、进程僵死、端口被占的时候，脑子里依然是一片空白。

这篇文章想给的不是又一份命令列表，而是一条可以按顺序走完的学习主线：先把 Shell、终端、命令三者的关系理顺，再搭一个随便折腾的练习环境，然后按“文件操作—文本处理—权限进程—磁盘网络”四层往下走，最后用一次真实风格的故障排查把前面所有命令串成一条链。判断标准也很明确：看完之后，你应该能在不看任何清单的情况下，独立完成“找文件、查日志、看负载、定位端口占用”这四类最日常的操作。

1. 为什么 Linux 命令值得系统学一遍

很多人对命令行的第一印象是“图形界面能做的事，为什么要敲一堆字母”。这个认知在单机桌面场景下不算错，但一旦涉及服务器、批量操作和可复现性，就会立刻翻转。图形界面的每一步操作都是一次性的、不可记录的、难以让别人重复的；而命令行天然是文本，文本可以被复制、被写进脚本、被塞进自动化流程，也可以被拷给同事说“你按这个跑一遍”。

举个最朴素的对比。假设你要在当前目录下把 200 个 .txt 文件统一改成 .md，用图形界面要逐个右键、重命名、改后缀，而且很容易在第 137 个的时候手滑改错。命令行只有一行：

bash复制for f in *.txt; do mv -- "$f" "${f%.txt}.md"; done

再比如排查线上问题，图形界面能给你一个进程列表，但给不了“最近 10 分钟日志里出现过哪些 ERROR，各自出现多少次”这种聚合视图，而这恰恰是定位问题最需要的信息：

bash复制grep "ERROR" app.log | awk '{print $4}' | sort | uniq -c | sort -rn | head -n 20

命令行真正的价值不在于“能做图形界面能做的事”，而在于它能把这些动作组合成新的动作。管道符 | 是这套组合能力的核心：前一条命令的输出直接变成后一条命令的输入，中间不需要落盘、不需要手工搬运。这个设计看起来平淡，实际上决定了 Linux 命令体系可以像积木一样拼装——grep 负责过滤、awk 负责取列、sort 负责排序、uniq 负责去重计数，四个命令拼出来的能力，远超任何一个单独的“日志分析工具”。

那么到底需要掌握到什么程度？一个比较务实的判断是：不需要背完 man 手册，但必须熟练到形成肌肉记忆的，大概在 30 到 40 条高频命令，并且要具备管道思维。 这 30 多条命令覆盖的正是后端开发、测试、运维、数据工程、算法部署这些岗位日常绕不开的四件事：找东西、看状态、改权限、跑批处理。剩下的几百条命令，用到的时候查 man 或者 --help 就够了，没有人真的全部记住。

2. 核心概念与命令语法框架

2.1 终端、Shell 和命令到底是什么关系

这是零基础最容易混淆的一组概念，混淆之后的直接后果是：看到报错信息不知道是终端的问题、Shell 的问题还是命令本身的问题。

终端（Terminal）是一个窗口程序，负责显示字符和接收键盘输入，它本身不执行任何命令。Shell 是跑在终端里的解释器，负责读取你敲的那行字符串，解析成命令和参数，然后交给系统执行。命令则是具体的可执行程序，或者 Shell 内置的一段逻辑。用一条命令就能把这层关系看清楚：

bash复制# 查看当前使用的 Shell
echo $SHELL
# 输出示例：/bin/bash

# 判断某条命令是 Shell 内置还是外部程序
type cd
# 输出：cd is a shell builtin

type ls
# 输出：ls is aliased to `ls --color=auto'  或  ls is /usr/bin/ls

区分内置命令和外部命令有实际意义。内置命令不产生子进程，执行速度极快，而且会直接影响当前 Shell 的状态（比如 cd 改变的是当前 Shell 的工作目录，如果它是外部程序，切目录就会失效）。外部命令则是磁盘上的可执行文件，which 可以查到它的位置：

bash复制which ls
# 输出示例：/usr/bin/ls

理解这层关系后，很多“玄学问题”就有了解释。比如你写了个脚本，脚本里 cd 之后目录没变，那是因为脚本跑在子 Shell 里，子 Shell 退出后父 Shell 的工作目录不受影响；再比如某些命令在交互式终端里能跑、放进 crontab 就失败，往往是因为 cron 环境的 PATH 和你登录时的 PATH 不一样，找不到对应的可执行文件。

2.2 一切皆文件与目录树结构

Linux 把设备、进程信息、内核参数都以文件的形式暴露出来，这被称为“一切皆文件”。这个设计带来的直接好处是：你只需要掌握一套文件操作命令，就能读写配置、查看硬件信息、监控进程状态。

目录树的结构由 FHS（文件系统层次结构标准）约定，不需要背全，但下面这几个必须知道各自放什么：

/proc 值得单独提一句，它不是真实存在于磁盘上的目录，而是内核在内存里生成的视图。所以下面这条命令能看到 CPU 信息，但它并不对应任何磁盘文件：

bash复制cat /proc/cpuinfo | grep "model name" | head -n 1
cat /proc/meminfo | head -n 3

2.3 命令的通用语法与帮助体系

Linux 命令的语法高度统一：命令 [选项] [参数]。短选项用单个连字符，可以合并写（ls -lh 等价于 ls -l -h）；长选项用双连字符，可读性更好（ls --human-readable）。参数通常是文件路径、用户名、进程号之类。

遇到不认识的命令，按这个顺序求助，效率最高：

bash复制# 1. 先看简短帮助，最快
ls --help

# 2. 需要完整文档时用 man，按 q 退出
man ls

# 3. 只想快速看几个常用例子
man -k "copy files"

man 手册分多个区段，同一个名字可能在不同区段有不同含义。比如 man 1 printf 是 shell 命令，man 3 printf 是 C 库函数。日常使用九成场景都在第 1 区（用户命令）和第 5 区（配置文件格式），第 8 区（系统管理命令）在查 mount、systemctl 这类命令时也会用到。

2.4 管道、重定向与输入输出

这是命令行的分水岭。不掌握管道，你只是在用命令行替代鼠标；掌握了管道，才开始真正用上 Linux。

每个程序默认打开三个文件描述符：0 是标准输入，1 是标准输出，2 是标准错误。重定向就是把这几个通道改接到文件上。

bash复制# 覆盖写入
echo "hello" > test.txt

# 追加写入
echo "world" >> test.txt

# 把标准错误丢弃，屏幕上只看正常输出
find / -name "*.conf" 2>/dev/null

# 标准输出和标准错误一起重定向到同一个文件
command > all.log 2>&1

# 管道：前一条命令的输出作为后一条的输入
ps -ef | grep nginx | grep -v grep

2>/dev/null 这个写法在实战里出现频率极高。find / 会遍历整个文件系统，必然撞上一堆权限不足的目录，报错刷屏把真正的结果淹掉。把标准错误丢掉，输出立刻清爽。

grep -v grep 也是老手习惯：ps -ef | grep nginx 会把 grep nginx 这条命令自己也匹配进去，加一层过滤把它排掉。现在更推荐用 pgrep -af nginx，一步到位。

3. 环境准备与练习环境搭建

学命令最怕两件事：一是没有环境，二是环境太重要。用公司生产服务器练 rm 和 chmod，属于典型的高风险行为。所以第一步是把练习环境搭起来，而且要选一个“删坏了也不心疼”的环境。

三种方式，按门槛从低到高排列。

方式一：WSL2（Windows 用户首选）。 不需要装虚拟机软件，也不需要分区，直接在 Windows 里跑一个完整的 Linux 内核。管理员权限打开 PowerShell 执行：

powershell复制# 查看已安装的发行版和运行状态
wsl -l -v

# 安装一个发行版（示例为 Ubuntu，实际可用版本以列表为准）
wsl --install -d Ubuntu

装完之后在开始菜单里能找到对应入口，第一次启动会要求设置用户名和密码。文件系统是互通的，Windows 下的盘符挂载在 /mnt/c、/mnt/d，这一点在跨平台开发时很方便，但要注意跨文件系统访问的性能比在 Linux 原生目录下慢不少，项目代码建议放在 ~/ 下面。

方式二：容器（最快，但有局限）。 本机装了 Docker 的话，一条命令就能进一个干净的 Linux 环境：

bash复制# 启动一个临时容器，退出后自动删除
docker run -it --rm ubuntu:22.04 bash

优点是启动快、完全隔离、随便折腾；缺点也很明显：容器里默认没有 systemd，systemctl 用不了，网络和存储也是容器视角，不适合练服务管理和磁盘排查。所以容器适合练文件操作、文本处理、权限这些纯用户态的东西，练系统管理还得用虚拟机或云服务器。

方式三：云服务器。 一台最低配的按量实例就够，用完释放。好处是最接近真实生产环境，能练 systemctl、journalctl、防火墙、SSH 登录这些内容。这里必须强调几点安全底线：安全组只放行必要端口，不要对公网开放 22 端口给所有来源；不要长期用 root 直接登录，创建普通用户后再按需提权；练习用的实例不要挂载任何真实数据。

环境就绪后，先跑几条命令确认基本情况：

bash复制# 系统发行版信息
cat /etc/os-release

# 内核版本
uname -r

# 当前 Shell
echo $SHELL

# 当前用户和所属组
id

这四条看起来简单，但在排查问题时价值很高。同一条命令在不同发行版上行为不一致是常事，比如包管理器在 Debian 系是 apt、在 RHEL 系是 yum 或 dnf；sed -i 在 GNU 版本和 BSD 版本上的参数格式也不同。先确认环境，再决定命令怎么写，能省掉大量“为什么我的命令报错”的困惑。

4. 文件与目录操作：最基础也最容易出事故

文件操作命令是所有人最先学会的，也是最容易酿成事故的。原因很简单：它们大多具有破坏性，而且一旦执行往往不可逆。

4.1 查看与切换

bash复制# 列出详细信息，-h 让文件大小变成人类可读，-a 显示隐藏文件
ls -lah

# 按修改时间倒序，最新的在最前面
ls -lt

# 显示当前绝对路径
pwd

# 切换目录，cd 不带参数回到用户家目录
cd /var/log
cd -
cd ~

cd - 是回到上一个目录，在两个目录之间来回切换时特别顺手。ls -lt | head 则是查“最近改动了哪些文件”的固定套路，排查配置被谁动过的时候很好用。

4.2 创建、复制、移动、删除

bash复制# 递归创建多级目录
mkdir -p ~/lab/logs/{app,db,nginx}

# 创建空文件，或更新已有文件的时间戳
touch ~/lab/logs/app/app.log

# 递归复制并保留权限、时间戳
cp -rp ~/lab/logs ~/lab/logs-backup

# 移动，目标存在且是目录时相当于剪切粘贴
mv ~/lab/logs-backup ~/lab/old

# 重命名
mv ~/lab/old/app.log ~/lab/old/app.log.bak

cp -p 保留权限和时间戳这一点经常被忽略。做备份恢复时如果不加 -p，文件权限会按当前 umask 重新计算，原本 600 的密钥文件可能变成 644，这就是一个实打实的安全隐患。

rm 必须单独说。它是不可逆的，没有回收站。最常见的两个事故是：变量为空导致路径塌陷，以及通配符写错。

bash复制# 危险写法：如果 DIR 未定义，命令会变成 rm -rf /
rm -rf $DIR/logs/

# 安全写法 1：加引号并用 ${VAR:?} 在变量为空时报错退出
rm -rf "${DIR:?}/logs/"

# 安全写法 2：先打印确认，再执行删除
echo "即将删除：/tmp/build-$(date +%F)"

在实际项目里更推荐的做法是：删除前先 ls 一遍确认路径，脚本中的删除操作统一加 set -u 让未定义变量直接报错，生产环境的重要目录设置成不可写。另外，rm 别名成 rm -i 只是在交互式终端生效，脚本里不会触发，别指望它兜底。

4.3 查找文件：find 与 locate

find 是文件查找的主力，按名称、类型、时间、大小、权限都能筛：

bash复制# 找出 7 天前修改过的日志文件
find /var/log -type f -name "*.log" -mtime +7

# 找出大于 100MB 的文件，并丢弃权限报错
find / -type f -size +100M 2>/dev/null

# 找出 30 分钟内被修改过的配置文件
find /etc -type f -mmin -30

# 找到后直接执行操作，注意 -exec 结尾的 \; 和 + 的区别
find /tmp -name "*.tmp" -type f -delete

-mtime +7 的含义是“修改时间大于 7 天”，不是“7 天前那一天”，这个语义经常被误解。-exec ... \; 会为每个文件启动一次进程，-exec ... + 会把文件批量传给一次进程，后者效率高得多。

locate 依赖预建索引，速度极快但结果可能过时，容器环境里通常没有安装，日常还是以 find 为主。

5. 文本处理与管道：命令行的真正威力

如果只能保留一类命令，我会保留文本处理这一组。服务器上没有 IDE，没有日志面板，所有问题最终都表现为一堆文本，能不能快速从文本里捞出有用信息，直接决定了排查效率。

5.1 grep：定位到行

bash复制# 递归搜索并显示行号，忽略大小写
grep -rni "timeout" /etc/nginx/

# 反向匹配，排除掉注释行和空行
grep -vE "^\s*(#|$)" /etc/nginx/nginx.conf

# 只看最近的错误，带上上下文各两行
grep -n -A2 -B2 "Exception" app.log | tail -n 50

# 统计匹配行数
grep -c "ERROR" app.log

-A 和 -B 是排查异常时最实用的参数，异常堆栈往往在报错行的后面几行，只看单行等于看半截信息。-E 开启扩展正则，-F 关闭正则按字面量匹配（搜含 [、* 这类字符的字符串时必用）。

5.2 sed：按行编辑

bash复制# 打印第 10 到 20 行
sed -n '10,20p' app.log

# 替换前先备份，-i.bak 会生成 app.conf.bak
sed -i.bak 's/8080/9090/g' app.conf

# 删除所有空行
sed '/^$/d' app.log > app.clean.log

这里有个坑必须提醒：sed -i 在 GNU sed（大多数 Linux 发行版）和 BSD sed（macOS）上的参数格式不同。macOS 上直接写 sed -i 's/a/b/' file 会报错，必须写成 sed -i '' 's/a/b/' file。在本地 Mac 上测好的脚本丢到 Linux 服务器上跑，这类差异是常见的翻车点。

5.3 awk：按列处理

bash复制# 打印第一列和第三列
awk '{print $1, $3}' data.txt

# 指定分隔符，统计某列求和
awk -F',' '{sum += $2} END {print "总计:", sum}' sales.csv

# 只处理包含 ERROR 的行，输出第 1 列和第 4 列
awk '/ERROR/ {print $1, $4}' app.log

awk 的默认分隔符是连续空白，处理的对齐文本特别方便；-F 可以指定任意分隔符，处理 CSV、冒号分隔的配置文件都很顺手。$0 表示整行，NR 是行号，NF 是列数，这三个内置变量用熟了能解决大半需求。

5.4 管道组合：把命令拼成一次分析

下面这条是日志分析里最经典的组合，统计访问量最高的前 10 个 IP：

bash复制awk '{print $1}' /var/log/nginx/access.log \
  | sort \
  | uniq -c \
  | sort -rn \
  | head -n 10

拆开看每一步都很简单：取第一列 IP、排序、去重并计数、按次数倒序、取前 10。组合起来就完成了一次本该写脚本才能做的事。这种“每个命令只做一件事，用管道串起来”的思路，是 Unix 设计的核心，也是命令行效率远高于图形界面的根本原因。

再看一个查大文件的组合，sort -h 支持按人类可读的大小排序：

bash复制du -h --max-depth=1 /var 2>/dev/null | sort -rh | head -n 10

6. 权限、用户与进程管理

权限和进程是零基础最容易绕过去、又在实际工作中最先撞上的两块内容。Permission denied 和 端口被占用 这两个报错，几乎每个接触服务器的人都遇到过。

6.1 权限模型：三段九位

ls -l 输出的第一列，比如 -rw-r--r--，第一位是文件类型（- 普通文件、d 目录、l 软链接），后面九位分三组，分别对应属主、属组、其他用户，每组三位是读（r=4）、写（w=2）、执行（x=1）。

bash复制# 给脚本加执行权限
chmod +x deploy.sh

# 数字法设置：属主读写执行，属组读执行，其他无权限
chmod 750 deploy.sh

# 递归修改属主和属组
chown -R appuser:appgroup /opt/myapp

# 查看当前 umask，新建文件权限 = 666 - umask，目录 = 777 - umask
umask

两个必须记住的点。第一，目录的执行位含义是“能否进入”，一个目录如果只有读权限没有执行权限，ls 能列出名字但 cd 进不去，这是新手非常容易困惑的现象。第二，不要用 777 解决问题。chmod 777 看起来一劳永逸，实际上是把安全边界直接拆掉，任何用户都能改写你的程序文件。正确的做法是查清楚服务以哪个用户运行，把属主和属组设对，权限按最小必要原则给。

软链接和硬链接也常被混淆。软链接类似 Windows 快捷方式，源文件删掉后链接失效；硬链接指向同一份数据块，删除任一链接数据都还在，但硬链接不能跨文件系统，也不能指向目录。

bash复制# 创建软链接，做版本切换时很常用
ln -s /opt/myapp/releases/v1.2.0 /opt/myapp/current

# 查看软链接指向
ls -l /opt/myapp/current

这种“软链接指向当前版本目录”的做法是发布系统的常见模式，回滚时只需要把软链接重新指向旧版本目录，不需要改动任何配置。

6.2 进程查看与终止

bash复制# 查看所有进程的详细信息
ps aux

# 按 CPU 占用排序，取前 10
ps -eo pid,ppid,user,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 11

# 实时监控，按 P 按 CPU 排序、按 M 按内存排序
top

# 查看进程树，确认父子关系
pstree -p | head -n 30

# 按名称查找进程
pgrep -af java

ps aux 和 ps -ef 的输出格式略有差异，前者是 BSD 风格，后者是 System V 风格，两者都能用，但脚本里最好固定一种格式，避免字段位置理解错位。

终止进程的信号选择是有讲究的：

bash复制# 先查占用 8080 端口的进程
ss -lntp | grep :8080

# 优雅停止，允许程序捕获信号后清理资源、关闭连接
kill -15 <PID>

# 等待几秒确认是否退出，仍不退出再用强制终止
kill -9 <PID>

-15（SIGTERM）是请求进程自行退出，程序有机会写完缓冲区、关闭数据库连接；-9（SIGKILL）由内核直接杀掉，程序没有任何反应时间，可能留下脏数据和锁文件。先 15 后 9，中间给几秒观察窗口，这个顺序应该成为条件反射。同理，killall 和 pkill 会按名称批量杀进程，在生产环境使用前务必用 pgrep -af 先确认匹配范围，避免误伤同名的其他服务。

7. 磁盘、网络与系统状态排查

这一组命令的共同特点是：平时用不上，一旦用上基本就是出事了。

7.1 磁盘空间：df 与 du 的区别

bash复制# 查看各文件系统使用率
df -h

# 查看指定目录下每个子目录的占用
du -h --max-depth=1 /var 2>/dev/null | sort -rh | head -n 10

df 统计的是文件系统层面的块使用情况，du 是累加目录下所有文件的大小。两者对不上是经常发生的事，最常见的原因是文件已被删除但仍有进程持有句柄，空间不会释放。这种情况 du 看不到，df 却一直显示满：

bash复制# 查找已被删除但仍被进程占用的文件
lsof +L1 2>/dev/null | head -n 20

确认之后，重启对应进程即可释放空间，或者在支持的情况下清空 /proc/<PID>/fd/<fd>。这是磁盘告警排查里非常经典的一环，不知道原理的话很容易陷入“明明删了文件，磁盘还是满的”的死循环。

7.2 内存与负载

bash复制# 内存使用，注意 available 才是真正可用的内存
free -h

# 系统负载、运行时长、登录用户数
uptime

free 输出里的 buff/cache 经常引起误解。Linux 会主动把空闲内存用来缓存磁盘数据，这部分内存在应用需要时可以被回收，所以判断内存是否紧张要看 available，而不是看 free 那一列。uptime 的三个负载值分别是 1 分钟、5 分钟、15 分钟的平均值，判断标准要结合 CPU 核数：8 核机器负载 8 属于跑满，4 核机器负载 8 就是明显过载了。

7.3 网络与服务状态

bash复制# 查看网卡地址
ip addr

# 查看监听端口，-l 监听 -n 数字端口 -t TCP -p 显示进程
ss -lntp

# 查看连接状态汇总
ss -s

# 测试 HTTP 接口是否通，只看响应头
curl -I https://example.com

# 带详细过程调试，排查证书、DNS、超时问题
curl -v --max-time 5 https://example.com

# DNS 解析
dig example.com +short

netstat 在很多新发行版里已经被 ss 取代，netstat 可能根本没有预装，ss 的性能也更好。排查“端口被占用”时，ss -lntp | grep :端口号 是最快的方式，前提是有权限读取进程信息，普通用户执行时进程名那列可能是空的，需要 sudo。

7.4 服务与日志

bash复制# 查看服务状态
systemctl status nginx

# 查看服务最近 100 行日志，不分页
journalctl -u nginx -n 100 --no-pager

# 按时间范围过滤
journalctl -u nginx --since "2024-01-01 10:00" --until "2024-01-01 11:00"

# 查看内核级消息，硬件报错、OOM 记录都在这里
dmesg -T | tail -n 30

dmesg -T 把时间戳转成可读格式，排查“进程莫名被杀”时，dmesg 里往往能看到 OOM Killer 的记录，这是判断是不是内存不足导致进程被内核干掉的关键证据。

8. 完整实战：定位一台“变慢”的服务器

前面每个命令单独看都不难，真正的门槛在于遇到问题时按什么顺序查。这一节用一个典型场景串起来：同事反馈某台服务器“访问变慢、偶尔超时”，你手上只有一个 SSH 连接。

排查顺序遵循从整体到局部、从便宜到昂贵的原则：先看负载和时间，再看 CPU 和内存，然后看磁盘和 IO，接着看网络和端口，最后翻日志找证据。

先把这些检查写成脚本，方便重复执行：

bash复制#!/usr/bin/env bash
# 文件路径：~/lab/health-check.sh
# 用途：一次性采集主机基础状态，只读操作，可安全执行
set -uo pipefail

echo "===== 1. 时间与负载 ====="
date '+%F %T'
uptime

echo "===== 2. CPU 占用前 5 的进程 ====="
ps -eo pid,user,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 6

echo "===== 3. 内存与交换分区 ====="
free -h

echo "===== 4. 磁盘使用率 ====="
df -h -x tmpfs -x devtmpfs

echo "===== 5. /var 下占用最大的 10 个目录 ====="
du -h --max-depth=1 /var 2>/dev/null | sort -rh | head -n 10

echo "===== 6. 监听中的 TCP 端口 ====="
ss -lntp 2>/dev/null

echo "===== 7. 最近的内核消息 ====="
dmesg -T 2>/dev/null | tail -n 10 || echo "dmesg 需要 root 权限，已跳过"

赋权并执行：

bash复制chmod +x ~/lab/health-check.sh
~/lab/health-check.sh

预期输出是分段的纯文本，每段前面有分隔标题。判断成功的标准很直观：七段内容都能正常打印，没有大面积报错。如果某一段报 command not found，说明对应工具没装，比如 dmesg 在精简容器镜像里通常没有；如果 ss 那段的进程名是空的，说明当前用户权限不够，加 sudo 再跑一次。

拿到输出之后怎么读，这里给几条经验判断：

第一，看 uptime 的负载和 CPU 核数是否匹配。用 nproc 查看核数，15 分钟负载持续高于核数的 1.5 倍，基本可以判定存在持续压力，而不是瞬时抖动。

第二，看 ps 里排第一的进程是不是你预期的。如果是一个 Java 进程占满 CPU，八成是 GC 频繁或者死循环；如果是一个 find 或者备份脚本，那就是定时任务撞上了业务高峰。

第三，看 df -h 里有没有使用率超过 85% 的分区。日志分区打满是线上最常见的事故之一，而且它引发的连锁反应很隐蔽：写日志阻塞导致接口超时，看起来像性能问题，实际是磁盘问题。

第四，看 free -h 的 available 和 swap 使用情况。swap 被大量使用说明物理内存不足，此时即使 CPU 不高，响应也会明显变慢，因为磁盘 IO 成了瓶颈。

第五，看 dmesg 有没有 OOM 记录。如果有进程被内核杀掉过，前面的“偶尔超时”就解释得通了。

假设脚本跑完发现 /var 使用率 96%，继续往下钻：

bash复制# 逐层定位大目录
du -h --max-depth=1 /var/log 2>/dev/null | sort -rh | head -n 10

# 找到具体的大文件
find /var/log -type f -size +500M -exec ls -lh {} \; 2>/dev/null

# 确认文件是否还被进程占用（防止删了不释放）
lsof /var/log/nginx/access.log 2>/dev/null | head -n 5

确认是 Nginx 访问日志过大后，正确的处理方式不是直接 rm，而是先清理历史内容再配置轮转：

bash复制# 清空内容但保留文件句柄，避免影响正在写入的进程
: > /var/log/nginx/access.log

然后用 logrotate 做定期轮转和压缩，这才是根治方案。直接 rm 掉日志文件，进程依然持有文件描述符，磁盘空间不会释放，问题会在几小时后原样复现。

9. 常见问题排查与工程最佳实践

9.1 高频问题对照表

9.2 工程最佳实践

破坏性命令必须做三重防护。 删除、格式化、批量改权限这类操作，执行前先确认目标路径（echo 打印一遍）、确认当前身份（id）、确认环境（hostname 区分测试和生产）。在脚本里统一加 set -euo pipefail：遇错退出、未定义变量报错、管道中任一环节失败即失败。这三条能挡掉大半低级事故。

配置修改永远先备份。 cp file file.bak.$(date +%F) 是一条成本极低、收益极高的习惯。sed -i 的 -i.bak 参数也能达到同样效果。修改系统级配置前，最好在测试环境验证一遍，确认服务能正常重启再上生产。

日志是排查的第一手证据，别急着删。 遇到问题先看日志，journalctl -u 服务名、应用日志的 tail -f、dmesg，三条路径覆盖了绝大多数场景。同时要建立轮转机制，别等到磁盘打满才想起日志。

命令要写进脚本，而不是留在终端历史里。 临时敲的命令只能解决一次问题，写成脚本才能沉淀下来。写脚本时注意加注释说明用途和风险，涉及到生产环境的脚本加上环境判断和二次确认。

权限从紧不给宽。 服务用什么用户跑，就把那个用户设成属主；不需要外网访问的服务不要绑 0.0.0.0；密钥文件权限设成 600；能用普通用户执行的操作不要用 root。这些原则在出事之前看起来多余，出事之后就是唯一的防线。

10. 学习路径与下一步方向

回到最开始的问题：命令不是背出来的，是在解决具体问题的过程中长出来的。这篇文章给出的分层框架——环境准备、文件操作、文本处理、权限进程、磁盘网络、故障排查——本身就是一条可以反复走的学习路径。

如果现在还没开始动手，建议先做三个练习，难度递增。第一个，在自己搭的环境里用 find 找出 /etc 下最近 24 小时被修改过的所有文件，并用 wc -l 统计数量。第二个，用 awk 和管道从一份日志里统计出访问量前 10 的 IP，并把结果重定向到文件。第三个，写一个和本文第 8 节类似的状态采集脚本，要求用 set -euo pipefail，并对磁盘使用率超过 80% 的情况输出醒目的警告行。这三个练习做完，日常工作中八成以上的命令场景都能覆盖。

再往后的方向有几个明显的分岔。一是 Shell 脚本编程，把重复操作自动化，重点是变量、条件、循环、函数、错误处理和参数解析；二是服务与进程管理，systemd 的 unit 文件、日志管理、开机自启、资源限制，这是运维方向的基础；三是性能与网络分析，strace、tcpdump、iostat、vmstat 这一批工具，适合需要在深水区定位问题的人；四是容器与编排，把命令能力迁移到容器视角，注意命名空间带来的差异。

最后提醒一句：命令行能力越强，误操作的破坏力也越大。所有的熟练都应该建立在“先确认、再执行”的习惯之上，而不是建立在“我手速快”的自信之上。真正的高手，往往在按下回车之前多看一眼路径。