Linux命令进阶：从shell原理到线上排查的实操指南

说到Linux常用命令，很多人第一反应都是收藏一张“XX个命令大全”，然后就没有然后了。我这些年带新人、帮朋友排查服务器问题，见过太多人卡在同一个地方：ls、cd、cat这类基础命令敲得飞起，可真丢一台线上服务器给他，从日志分析到磁盘清理，能折腾一下午。问题不在于命令背得不够多，而在于没搞清楚每条命令背后那个真正的主线——你是在跟操作系统对话，不是在背单词。

这篇文章不想再给你铺一张无所不包的字典式清单，而是按一个真实使用者的成长路径来写：从刚登录服务器时的不知所措，到能独立完成日志统计、权限分配、服务部署和故障排查。每一章都会把“为什么这么用”讲清楚，再补一些我在线上环境踩过的坑。无论你是刚开始学Linux，还是已经在写脚本但总觉得基本功不扎实，都可以照着敲一遍。

1. 先搞清楚你在和谁说话：命令执行前发生了什么

1.1 shell不是“翻译官”，它本身就是一个程序

很多教程把shell比喻成“用户和内核之间的翻译官”，这个说法容易让人误解，好像shell只是个中间层。实际上，你在终端里敲下 ls -l 然后回车，shell做的事情比“翻译”复杂得多。

第一步是解析命令行。shell会先看你输入的内容里有没有变量、通配符、别名。比如你敲 echo $HOME，变量展开这一步是shell完成的，echo 这个程序收到的参数已经是展开后的路径了，不是 $HOME 这个字符串。同理，rm -rf *.log 里的 *.log 也是shell先展开成匹配到的文件名，然后 rm 才真正执行。

这也是为什么在脚本里写 find . -name "*.log" 时，很多人会疑惑为什么要加双引号。因为如果你不加引号，shell可能在 find 运行之前就把 *.log 展开成当前目录下的一堆文件名，结果 find 的行为就完全变了。搞清“哪些字符是shell处理的，哪些是命令自己处理的”，是减少命令报错的第一道基本功。

1.2 type命令能帮你分清内建命令和外部命令

遇到“明明有这个命令，为什么执行报错”的时候，第一步不是去查PATH，而是用 type 看这个命令到底是什么类型。

我举个例子。cd 这个命令，你 which cd 试试，会发现找不到可执行文件。因为它根本不是外部程序，而是bash的内建命令。内建命令是shell自带的功能，不需要去磁盘上加载外部程序，这也是为什么 cd 能改变当前shell的工作目录——如果它是一个独立进程，怎么可能改变父进程的目录呢。

用 type -a 可以查看一个命令所有可能的解析路径。在排查“我改了配置但命令还走老路径”这种问题时，type -a 简直是救命稻草。比如你明明装了新版本的python，结果敲 python 还是旧的，先跑一下 type -a python，八成是PATH里面旧路径排在前面，或者存在alias。

另外一个常被忽略的是命令哈希缓存。bash为了提高效率，会把用 hash 记录过的命令路径缓存在当前shell里。如果你新装了一个程序，或者手动调整了某个可执行文件的位置，当前shell可能还是按缓存里的旧路径执行。这种情况下执行 hash -r 清空缓存，问题通常就解决了。

1.3 alias虽方便，但要注意它的生效范围

为了敲起来省事，很多人会在 .bashrc 里写一堆alias，比如 alias ll='ls -l'。这个做法本身没错，但有几个细节很容易踩坑。

第一，alias默认只在交互式shell里生效。你写进 .bashrc 的alias，写脚本时是不生效的。因为脚本运行时用的是非交互式shell，根本不会加载 .bashrc 里定义的alias。所以如果你在脚本里依赖某个alias，大概率会收到 command not found。

第二，alias的展开发生在命令解析的早期阶段。也就是说，如果你定义了 alias ls='ls --color=auto'，递归展开可能会导致死循环，所以bash对alias展开后的命令不会再做alias解析。这一点大多数情况下是好事，但也意味着你很难在一个alias里引用另一个alias的值。

第三，临时绕过alias的方法是 \ls 或在命令前加 command ls。当你的alias把某个命令包装得过于复杂，而你又想看原始输出时，这个技巧很有用。我在排查问题时经常用 \grep 来跳过alias里加的参数。

2. 文件与目录不是“会用”，而是“熟用”

2.1 ls -l输出里藏着的关键信息

如果只能挑一个命令来检验Linux基本功，我会选 ls -l。不是因为它难，而是太多人只会看文件名和大小，忽略了输出里那些对排错至关重要的字段。

拿一行典型输出来说：

bash复制drwxr-xr-x 3 root root 4096 Jun  8 10:23 nginx

第一个字符 d 代表文件类型。- 是普通文件，d 是目录，l 是软链接，b 和 c 分别代表块设备和字符设备。我见过有人拿 ls -l 去找软链接指向的目标，结果看半天没看到，原因就是没意识到第一列是 l 的话，输出行末尾会跟着一个 -> 目标路径。

后面九个字符是权限位。rwxr-xr-x 可以拆成三组，分别对应文件属主、属组、其他人。真正要理解的是，对于目录来说，r 决定你能不能列出目录内容，w 决定你能不能在这个目录里新建或删除文件，x 决定你能不能进入这个目录。所以一个目录权限如果是 rw-r--r--，你只能看目录里有什么，但没法 cd 进去，也无从读取里面的文件内容。这个细节在配置Web目录、NFS共享时特别容易踩坑，因为很多人只关注文件本身的权限，忽略了上级目录的 x 权限。

再往右是硬链接计数。对普通文件来说，这个数字代表有几个硬链接指向同一个inode；对目录来说，它的值是“子目录数加2”。数字下面是属主和属组，然后是文件大小，最后是修改时间。用 stat 命令可以看到更详细的时间戳信息，包括访问时间、修改时间、状态变更时间，这在排查文件为什么被动过时很有用。

2.2 cp、mv、rm的几个“反直觉”细节

cp 和 mv 看起来太基础了，但恰恰是基础命令最容易在服务器上酿成大祸。

先说 cp。很多人从网上抄命令，喜欢加 -r 复制目录，却不一定知道 cp -r 对软链接的处理方式。默认情况下，cp -r 复制一个目录时，如果里面包含软链接，它会复制软链接本身，这通常没问题。但如果你用 cp -rL，它会顺着软链接把目标文件的内容也复制过来，结果生产环境的配置目录被复制成了完全不同的样子。

我自己的习惯是，能不用 cp -r 就不用，优先用 rsync -a。rsync 的 -a 包含 -rlptgoD 这一组选项，能保留软链接、权限、时间戳和属主信息。更重要的是，rsync 可以断点续传，可以只同步变化的部分，在迁移服务器、备份目录时比 cp 稳太多。

rm 的坑就不用多说了。rm -rf 配合变量使用的时候，永远要警惕变量为空的情况。比如脚本里写 rm -rf /home/$user/backup，如果 $user 这个变量因为某种原因没赋值，命令就变成了 rm -rf /home/backup，这还算好的；万一变量里带了斜杠，后果更严重。我的防御性做法是：先 cd 到安全目录，用相对路径删除，或者删之前先 echo 打印完整路径确认一遍。更稳健的方案是把要删的目录先 mv 到一个临时目录，确认没问题后再清空，相当于给 rm 加了个“回收站”。

mv 也有个容易被忽略的点：跨文件系统移动时，mv 的原子性是不存在的。它会先复制再删除源文件，如果中途出错，源文件可能已经没了。所以跨磁盘移动大目录时，我一般不用 mv，而是用 rsync 复制完并校验成功后，再删除源目录。

2.3 查看文件内容的五个工具，对应五种场景

cat 适合看短文件，这个没什么争议。但如果你直接 cat 一个几百MB的日志，终端会卡死，这时候就要分场景选工具了。

tail -f 是排查线上问题时最常用的命令，它可以持续跟踪文件的新增内容。部署服务、看报错日志的时候，我通常会开一个终端窗口专门跑 tail -f /var/log/nginx/error.log，这样配置一刷新，错误立刻就能看到。tail -n 100 则适合先看最近100行，快速定位有没有异常。

less 是我看大文件的首选。它打开文件时不是一次性加载到内存，而是按需读取，所以即使是几个GB的日志也能流畅翻页。进入 less 之后按 / 可以搜索关键字，按 n 跳到下一个匹配结果。这个工具的最大优势是“大文件不乱”，而且查看过程中不会把文件内容刷到终端缓冲区。

head 适合看文件开头，比如查看配置文件的模板说明。sed -n '100,200p' 这类写法适合精确抽取文件的连续区间行，但日常用 sed 更多是流式处理，具体放到后面文本处理章节再说。

文件查看的需求可以简单总结成一个表格：

工具没有高低之分，只有合不合适。看到一个文件，第一时间想清楚“我到底要它的全部、开头、结尾、还是中间某一段”，再去选命令，效率会高很多。

2.4 软链接和硬链接，用错场景会出问题

软链接像一个快捷方式，它是一个独立的文件，里面存着目标路径。目标文件被删除后，软链接就变成断链，但软链接本身还活着。硬链接则不同，它和原文件共享同一个inode，删除其中一个名字，另一个名字依然能访问文件内容，因为inode的引用计数没有归零。

日常运维中，软链接用得最多。比如把Java版本切换成软链接指向不同目录，或者把日志目录软链到数据盘，都是正常操作。但硬链接有一个使用场景需要注意：当你需要确保某个文件“删错了也能恢复”时，给文件建一个硬链接可以防止内容真正被释放，但要小心它会给后来的维护者造成困惑，因为你在两个路径看到的是同一个文件。

我个人建议，如果只是想要“备份一个文件的当前状态”，用 cp 更直观；如果想要一个“可以随时切换版本”的入口，用 ln -s；硬链接在日常运维里出现的频率不高，但它能解释为什么某些目录的大小统计显得“不对”——同一个inode被多个名字引用时，du 和 ls 的统计口径会不一样。

3. 文本处理不是“背参数”，而是建立管道思维

3.1 grep排除干扰：过滤日志先学会做减法

Linux服务器上大量问题的答案都藏在日志里，而日志分析的第一步几乎都是 grep。但大部分人对 grep 的使用停留在 grep ERROR app.log 这一个层面上，这远远不够。

真正排查问题的时候，噪音往往比信号多。比如你要找日志里的报错，直接 grep ERROR 会混进大量无关信息，反而把真正严重的问题淹没。我会先用 grep -c 统计数量，感受一下问题的规模分布，再通过 grep -E 使用扩展正则，把多个关键词合并过滤。

grep -v 是反向匹配，也就是“排除”。比如日志里大量出现健康检查的请求，干扰你看真实业务日志，就用 grep -v "healthcheck" 把它们筛掉。还有一个很有用的场景是配合管道，先用 tail 取最近N行，再管道给 grep 搜索关键字，避免在超大日志里做全量扫描。

grep -r 递归搜索目录的能力也很实用。不过要注意，如果你在一个挂载了网络存储的目录上用 grep -r，性能可能会非常差，因为网络IO延迟会拖慢整个搜索过程。更高效的方案是用 grep -r --include='*.log' 限定文件类型，或者干脆用 find 先定位出候选文件，再逐个 grep。如果搜索量实在太大，可以考虑用 zgrep 直接搜索压缩过的日志，很多日志轮转工具产生的 .gz 文件都能这样处理。

3.2 sed做批量修改时，最容易栽在“范围”上

sed 是做非交互式文本修改的利器，尤其在批量替换配置时，它比打开Vim手动改几十个文件高效得多。

最经典的用法是：

bash复制sed -i 's/192.168.1.10/192.168.1.11/g' /etc/app/config.ini

这里的 s 是替换命令，g 代表全局替换。如果不加 g，每行只替换第一个匹配到的结果。-i 代表原地修改，但在生产环境我强烈建议先用不带 -i 的版本跑一遍，把输出结果肉眼确认一下，无误后再加 -i 真正写入。更保险的做法是 sed -i.bak，这样会先自动生成一个 .bak 后缀的备份文件，改错了还能退回。

sed 的“范围”概念是很多新手痛苦的来源。比如你只想改某个特定行号范围里的内容，可以用 sed -n '20,50p' 先预览修改前的内容，或者 sed '20,50s/foo/bar/g' 只在第20到50行之间做替换。还可以用正则匹配范围，比如 sed '/<database>/,/<\/database>/s/host/hostname/' 只处理两个标记之间的内容。稍有不慎，范围就会比你想的更宽，所以改之前预览永远是值得的。

还有一个很实用的场景是删除行。sed -i '/^#/d' config.conf 可以删除所有以 # 开头的注释行。但注意，如果某些配置行是“行内注释”，比如 key=value # explanation，这种写法用上面的命令就删不干净，需要配合更精细的正则或者直接用awk。

3.3 awk按列处理，日志统计的第一课

如果说 grep 和 sed 都是按行做文章，awk 的价值就在于让你能跳到“列”的维度。

看一个最常见的场景：统计Nginx访问日志里哪些IP访问次数最多。日志的格式通常是IP在第一列，一行一个请求：

bash复制awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20

这里 $1 就是取第一列。sort 先把相同的IP排到一起，uniq -c 统计每个IP出现的次数，再 sort -rn 按次数从大到小排列，最后 head -20 只取前20名。这个组合堪称日志分析的“第一公式”，适用范围极广，不只是IP，任何能按列拆出来的字段都能这样统计。

awk 还支持条件过滤。比如你要找状态码不是200的请求：

bash复制awk '$9 != 200 {print $1, $7, $9}' access.log | head -50

$9 是Nginx日志里状态码所在的列，$7 通常是请求路径。这种写法的好处是，你可以在日志量很大的时候，“边读边过滤”，而不用先把整个文件读进内存。awk 默认按空白分隔列，如果要处理的是按逗号分隔的CSV文件，可以用 -F',' 指定分隔符。不过如果CSV字段里本身包含逗号的话，用 awk -F',' 会切错，这种情况建议改用专门的CSV工具或者python处理，不要在awk里硬刚。

除了这些，awk 可以内嵌条件判断和循环，本质上是一种迷你语言。对大多数人来说，不需要把它学成一门编程语言，能灵活使用 $1、$NF、条件判断、内置变量 NR（当前处理到第几行）和 NF（当前行有多少列）就够了。我真正常用的awk功能，大概不超过十个关键字。

3.4 管道和重定向，才是“命令组合”的黏合剂

单独学一条命令效果有限，真正的威力来自把它们用管道串起来。管道的符号是 |，它的含义是“把左边命令的标准输出，作为右边命令的标准输入”。这不是简单的文件传递，而是两个进程之间实时的数据流，左边输出多少，右边就能处理多少。

重定向也同样重要。> 会把输出覆盖写入文件，>> 是追加写入。强烈建议把输出重定向到日志文件而不是任由它刷屏，比如跑定时任务时：

bash复制0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

这里的 2>&1 意思是把标准错误也并入标准输出，不然脚本跑挂了你只会看到任务“好像没执行”，去日志里一查，错误信息根本没记录下来。很多人分不清 > 和 2> 的区别，简单记：1是标准输出，2是标准错误。2>/dev/null 就是把错误信息丢弃掉，这在“我不想看权限报错噪音”时很有用，但生产环境慎用，因为你会把真正的错误也一起丢掉。

管道思维的核心是：每一条命令只做一件事，然后把输出交给下一条命令去做下一件事。这样的风格让排查链路变得清晰，也容易定位是哪一步的统计逻辑出了问题。

4. 用户、权限与进程，线上安全的第一道防线

4.1 权限位的真实含义：为什么755对目录和文件的意义完全不同

权限这关过不了，后面很多东西都看不明白。拿最常见的 755 来说，拆开是 rwxr-xr-x。把它当作二进制位来看，rwx 分别对应4、2、1，拼起来是7，所以 7 表示完整权限，5 表示 r-x，也就是可读可执行，但没有写权限。

数字权限的优势在于简洁，但不要只记数字。要理解的是，赋予一个文件 755 和赋予一个目录 755，含义有很大差别。

对于普通文件，x 代表可执行，所以二进制程序、脚本需要 x 才能运行。对于目录，x 代表“能否进入”，也就是能否把它当作工作目录。目录的 r 只代表“能列出目录下的文件名”，如果你只有 r 没有 x，你会发现 ls 能列出名字，但无法访问其中任何文件的路径，因为路径解析需要一级一级目录的 x 权限配合。

我在处理Web服务权限问题时的经验是：代码文件一般设置 644，目录设置 755，运行用户只对日志和上传目录有写权限。如果程序报“Permission denied”，先用 ls -ld 看目录权限，再用 ls -l 看文件权限，确认当前进程用户是否在这些权限的覆盖范围里，不要一上来就 chmod 777。777 能解决一时之痛，但会让任何用户都能修改你的文件，这在有公网访问的服务上是很大的隐患。

4.2 用户和组管理：用最小权限跑服务

Linux里的用户管理命令并不复杂，真正的挑战在于知道“该建什么样的用户来跑什么服务”。

我见过很多线上服务器，所有服务都用root启动。这样运行确实省事，但一旦应用被攻破，攻击者拿到的是root权限，整台机器就完全沦陷了。正确习惯是给每个服务创建独立的系统用户，只授予它必要目录的权限。

创建系统用户的常见做法是：

bash复制useradd -r -s /sbin/nologin -d /opt/myapp myapp

这里 -r 表示创建系统用户，-s /sbin/nologin 表示这个用户不能登录shell，-d 指定它的home目录。这样一来，服务进程可以用 myapp 用户运行，但如果有人想通过这个用户登录服务器，会被直接拒绝，因为它的shell是 /sbin/nologin。

用户创建之后还要管理密码和组。passwd 命令可以修改当前用户的密码，usermod -aG groupname username 可以把用户加入附加组。注意 -aG 里的 -a 是“追加”的意思，如果不加 -a，用户会被移出其他所有组，只剩下你指定的那个组，这可能不是你想要的效果。

查看用户信息时，id username 可以快速列出用户的UID、GID和所属组，这在排查文件属主问题时非常有用。手动查看 /etc/passwd 时要注意，文件每一行有七个字段，依次是用户名、密码占位符、UID、GID、注释、home目录、登录shell。看到 UID 为 0 的账号要格外警惕，因为 UID 0 就是超级用户，普通用户的 UID 通常从1000开始。

4.3 进程管理：从查端口到杀进程的完整链路

进程管理是排查服务器问题时绕不开的一环。先说需求场景：服务端口起不来，提示端口被占用。这时候第一步是找到谁占了这个端口。

bash复制ss -lntp | grep 8080

ss 是 netstat 的现代替代品，输出更清晰、速度更快。-l 表示只显示监听中的连接，-n 用数字显示端口和地址，-t 限定TCP协议，-p 显示进程信息。运行后你会看到类似 users:(("java",pid=12345,fd=114)) 的输出，里面的 pid 就是占用进程的编号。

找到PID之后，可能用 ps -fp PID 查看这个进程的详细信息，确认它到底是谁启动的。如果想看进程启动时的完整命令行，包括所有参数，用 ps -fp PID 还不够，需要 ps -ef 或者查 /proc/PID/cmdline。

真正杀进程时，我习惯先用 kill PID，也就是发送 SIGTERM 信号，让进程自己清理善后。只有等了几秒发现进程还没退出，才考虑 kill -9 PID。SIGKILL 是内核直接强制终止，进程来不及做任何清理，可能会导致数据文件损坏或者端口没释放干净。有些服务（比如Java应用）对 SIGTERM 会做优雅停机，直接把 kill -9 打上去，容易留下很多临时状态，得不偿失。

还有一个高频需求是“找出某个服务进程到底在哪”。pgrep -f 可以按进程名或者完整命令行匹配：

bash复制pgrep -af "nginx"

这会列出所有命令行里包含 nginx 的进程及其PID，适合找守护进程的子进程。但注意 pgrep -f nginx 也有可能匹配到你正在敲的命令本身，所以看到结果要多看一眼。

如果你管理的是systemd系统（大多数现代发行版都是），服务状态和启停应该优先用 systemctl。systemctl status nginx 会显示服务现在的运行状态、最近日志、PID等信息。systemctl restart nginx 是重启服务，systemctl enable nginx 是设置开机自启。能走systemd管理就不要自己用 nohup 起进程，因为systemd会负责崩溃重启、日志收集、开机启动等一系列问题，比自己写启动脚本靠谱得多。

5. 磁盘、网络与系统状态，排查顺序比命令重要

5.1 磁盘告警之后，怎么快速定位大文件

服务器磁盘报警是运维群里最常见的告警之一。遇到这种情况，第一步永远是 df -h，确认到底是哪个分区满了。有时候 / 满了，有时候 /home 满了，原因千差万别，不要凭感觉去清理。

确定分区之后，用 du 逐层找大目录。我的习惯是从根目录或者挂载点开始：

bash复制du -h --max-depth=1 /var | sort -hr | head -20

--max-depth=1 让 du 只统计 /var 下一级目录的大小，sort -hr 按人类可读的大小排序。这样一层层往下钻，很快就能锁定是哪个目录在膨胀。这条路最怕的是遇到大量小文件，du 会跑得很慢。遇到超大量文件时，可以先 du --max-depth=1 看总大小，不要直接逐文件列举。

磁盘空间还有一种常见的隐形杀手是“文件被删除但空间没释放”。进程打开了某个文件，你 rm 删掉了文件名，但那个进程还持有文件句柄，空间不会被真正释放。遇到 df 显示满、但 du 找不出大目录的情况，用 lsof | grep deleted 看看是不是有进程拿着已删除的文件。找到PID后重启那个进程，空间才会回来。这个坑我遇到过好几次，印象特别深。

5.2 网络排查按链路顺序走，别上来就想着抓包

网络问题排查最容易让人手忙脚乱，因为可能出问题的环节太多：本机服务没监听、防火墙挡了、安全组没放行、域名解析错了、中间网络丢包。所以顺序很重要。

我自己的排查顺序一般是这样的：

bash复制ping -c 4 目标IP

ping 看的是三层连通性。它通，说明路由和基本网络是通的。但它不通，也不代表应用一定不通，因为很多服务器出于安全考虑会禁ping。

接着看端口连通性。传统工具 telnet IP 端口 很直观，但很多系统默认没装telnet客户端。更推荐 nc -vz IP 端口，nc 的 -z 模式只扫描端口，不发送数据，速度快，适合批量测试端口。如果本机服务正常但外部连不进来，十有八九是防火墙或者云安全组规则的问题。

本机到底有没有在监听这个端口，用 ss -lntp | grep 端口 查。如果本机 curl http://127.0.0.1:8080/ 有响应，但用公网IP访问不通，那问题大概率不在服务本身，而在防火墙、安全组或者nat映射上。

检查HTTP接口时，直接用 curl -I 看响应头是最快的办法。curl -I 只请求HEAD信息，不会下载整个页面。如果接口返回很慢，可以加 -w 参数看耗时细节：

bash复制curl -o /dev/null -s -w "连接耗时: %{time_connect}s，总耗时: %{time_total}s\n" https://example.com

这样能区分是建立连接慢，还是传输数据慢，对定位网络性能问题非常有帮助。

5.3 系统负载、内存和IO，机器到底行不行

系统性能问题，我习惯在开终端后先跑三组命令。

第一组是 uptime，它的输出最后有一个load average值，比如 load average: 0.30, 0.45, 0.51。这三个数字分别代表过去1分钟、5分钟、15分钟的系统负载。负载这个指标要结合CPU核数来看：一个4核的机器，负载小于4说明CPU还没有完全被打满，如果超过4持续走高，说明可能有大量进程在等待CPU。

第二组是 free -h，看内存。重点看available列，它才是应用实际可用的内存量。buff/cache占用的内存如果有压力会被内核释放，所以不要看到cache高就觉得内存不够。

第三组是 top 或 htop。top 进入交互界面后按 P 按CPU排序，按 M 按内存排序。如果想看进程的实时状态，注意 %CPU 如果超过100，说明该进程使用多核并行。top 里还有一个load关键信息在头部：有多少running任务，有多少等待IO的任务。如果大量任务在D状态（不可中断睡眠，通常代表等待磁盘IO），CPU核数再多，整体性能也上不来，因为瓶颈在存储上。

磁盘IO的详细情况可以配合 iostat -x 1 来看，重点看 %util 和 await。%util 接近100不代表磁盘坏了，只代表磁盘比较忙；更关键的是 await，它表示IO请求从发出到完成的平均等待时间。如果 await 明显升高，说明存储确实成为瓶颈了。这些指标不是每次都要盯，但服务器卡顿的时候按这个顺序查一遍，能帮你快速缩小范围，避免病急乱投医。

6. 不止会敲，还要会串：三个能直接上手的组合场景

6.1 日志场景：找出访问量最大的IP，并看它都在请求什么

假设你手头有一个Nginx访问日志。现在的问题不是“文件里有没有异常”，而是“这个文件太大，肉眼根本看不过来”。这时把前面学的管道、文本处理、排序组合起来。

找访问量Top 10 IP的命令：

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

这条命令输出的第一列是次数，第二列是IP。看到某个IP次数明显异常，下一步要搞清楚它在请求什么，可以再加条件过滤：

bash复制grep "1.2.3.4" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

这里 $7 是请求路径。如果排在前面的都是同一个URL而且带大量查询参数，基本能判断是脚本在刷接口。要追得更深，可以把User-Agent也拉出来看：

bash复制grep "1.2.3.4" /var/log/nginx/access.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -5

-F'"' 指定双引号作为字段分隔符，这样第6个字段就是User-Agent。如果UA看起来像curl或者python脚本，那基本实锤不是正常浏览器访问。处理方式可以结合防火墙或Nginx的deny配置，把异常IP封掉。

6.2 定时清理旧文件，背后不只是一条find命令

“删除7天前的备份文件”是面试和日常工作里都很常见的需求。很多人直接写：

bash复制find /backup -type f -mtime +7 -delete

这条命令本身能跑通，但直接放进生产环境的crontab里有几个隐患。

find 的 -mtime +7 是按“24小时”为粒度计算的，意思是文件的修改时间距现在超过168小时。如果你的备份任务每天固定在凌晨执行，+7 通常能刚好留下最近7个文件。但如果你某天手动跑了一次备份，时间戳乱了，计算就可能出现偏差。更精确的做法是使用 -mmin +10080（10080分钟=7天），虽然步骤上差不多，但按分钟计算对定时任务来说更直观可控。

另外一个坑是 find ... -delete 如果遇到目录，会先尝试删除目录里的内容，然后删除目录本身。如果你本意是清理文件，结果指定了顶层目录，可能会把整个目录结构删掉。稳妥的写法是先用 -name 限定文件名模式，比如 find /backup -type f -name "*.sql.gz" -mtime +7，先不带 -delete 跑一遍，确认列出来的文件确实都是要删的备份，再补上 -delete。

crontab还有一个经常翻车的地方：环境变量。cron执行脚本时的PATH和交互shell不一样，可能找不到 find 或 mysqldump。所以脚本开头最好写全路径，或者在脚本第一行加 source /etc/profile 把基础环境变量引进来。日志输出也别忘了重定向，否则cron执行出错时，你只能收到一封不知道在说什么的系统邮件。

6.3 部署一个小服务，串起用户、systemd和命令路径

最后一个场景用一个最简单的例子来收尾：给应用创建独立用户，用systemd管理启动，并且保证每次开机都能自动拉起。

假设要部署的是一个Java应用，jar包放在 /opt/myapp/app.jar。先创建运行用户：

bash复制useradd -r -s /sbin/nologin -d /opt/myapp app

然后把jar包的属主改成这个用户：

bash复制chown -R app:app /opt/myapp
chmod 755 /opt/myapp/app.jar

接着写一个systemd服务文件 /etc/systemd/system/myapp.service：

ini复制[Unit]
Description=MyApp Service
After=network.target

[Service]
User=app
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/java -jar /opt/myapp/app.jar
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

这里的 User=app 指定进程运行用户，Restart=on-failure 表示进程异常退出时自动拉起，RestartSec=5 等待5秒再重启。确认路径后：

bash复制systemctl daemon-reload
systemctl start myapp
systemctl enable myapp

enable 会让systemd在开机时自动启动这个服务。之后排查都走 systemctl status myapp，日志则用 journalctl -u myapp -f 实时查看，而不是再用 nohup 和手工管理的日志文件。

整个流程看起来简单，但它把用户权限、systemd配置、路径管理、日志管理这些点串成了一个完整闭环。这其实就是“进阶”的核心：单个命令本身不难，难的是你知道在真实的系统里，它们如何配合起来组成一套可靠的运行机制。能独立完成这样一个小闭环之后，再回去翻命令大全，你会发现每一条命令都有了它的位置。