南瓜丶奇迹师1. 从一次线上排查说起：命令不是背的，是组合用的
前阵子帮一个朋友处理服务器问题，他发来一张截图，load average 已经到了 8，后面跟着一句：“怎么办？”我回他：“先看看 top，哪个进程在最上面？”过了几分钟，他又发来一张 ps aux 的截图，说：“有十几个 Java 进程，我不知道该看哪个。”
那一刻我意识到，他的问题不是不会敲命令，而是不知道命令和命令之间怎么串起来。很多刚开始接触 Linux 的人都有这个阶段：ls、cd、ps、top 这些常用命令都会用，但真到了排查故障的时候，脑子是空的。这也是为什么我把这个系列写到第十三篇，决定换一种讲法——不再单独罗列命令，而是把高频命令放进真实场景里，讲它们的组合用法。
这篇内容主要面向两类人：刚入行的运维或后端开发，以及那些平时用 Linux 不多，但偶尔要上服务器查日志、看进程、测端口的测试和嵌入式工程师。我会从最典型的排障场景出发，把文件查找、进程分析、网络定位、权限检查、日志统计这些高频动作全部串起来。
读完你会发现，命令还是那些命令，但用的时候不再是“想到哪个敲哪个”，而是按一条链路走下来。学会这种链路思维，比多背二十个命令有用得多。先说一个我自己的习惯：接到任何 Linux 相关问题，我脑子里先蹦出来的不是具体命令，而是一张流程清单——资源层面有什么异常，进程层面是谁造成的，网络层面通不通，日志层面怎么说的。每张清单对应几条命令，排查起来就有条理了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 文件定位与内容检索：find、grep 的高频组合打法
找文件、找内容是 Linux 上最常做的事情。很多人习惯 cd 到目录里一层层 ls，或者打开一堆文件去翻，效率很低。实际上，文件定位这件事有两条路：按名字和属性找，用 find；按文件内容找，用 grep。两条路组合起来，几乎能解决所有“文件在哪儿”的问题。
2.1 find 不是简单的“按名字找”
find 的核心价值在于“按条件找”，而且条件可以叠加。文件大小、修改时间、属主、权限、目录深度都能作为筛选条件。举几个高频组合：
bash复制# 在 /var/log 下找 .log 结尾、超过 500MB、三天前修改过的文件
find /var/log -name "*.log" -type f -size +500M -mtime +3
# 在整个系统中找属于 www-data 用户的配置文件，避开权限报错输出
find / -name "*.conf" -user www-data 2>/dev/null
# 在当前目录往下最多两层，找 30 分钟内被修改过的文件
find . -maxdepth 2 -mmin -30
这里有几个容易踩坑的细节。
第一，-mtime +3 表示“超过 3 天前修改”，-mmin -30 表示“30 分钟内修改”。+ 和 - 的方向一定不能搞反，+3 是往过去数，-3 是 3 天以内。这个逻辑刚开始用很容易反，我建议你直接记一组对照：-mtime -1 是最近一天，-mtime +7 是一周以前的。
第二，find / 全盘扫描时，普通用户会遇到一堆 Permission denied 的提示，输出刷屏不说，还会干扰你判断。最后加 2>/dev/null 把错误输出丢进黑洞，是标准动作。这也是初学者最容易忽略的细节。
第三，find 拿到结果之后怎么处理？常见做法是配合 -exec 执行动作：
bash复制# 找到临时文件后删除，注意 {} 和 \; 的写法
find . -name "*.tmp" -type f -exec rm {} \;
如果你对批量删除不放心，可以先执行 -exec ls -lh {} \; 看看结果，确认没问题再换成删除命令。更保守的方案是用 -ok，它会在执行每条命令前询问一次，适合在生产环境操作。
我个人的习惯是，能用 find 的 -size、-mtime 缩小范围就绝不裸搜。搜索范围越小，命令跑得越快，误伤的概率也越低。
2.2 grep 帮你在内容里捞针
文件内容检索绕不开 grep。它的高频用法是递归搜索加过滤：
bash复制# 在 nginx 配置目录里递归搜 listen 关键字
grep -rn "listen" /etc/nginx/
# 只搜 .conf 文件，排除其他类型
grep -rn --include="*.conf" "listen" /etc/
# 拿进程列表过滤目标程序，同时排除 grep 自身
ps aux | grep "nginx" | grep -v grep
-r 递归目录，-n 显示行号，-i 忽略大小写，--include 限定文件类型。这些参数基本每次排查都会用到。
有一个经典笑话式的坑，就是 ps aux | grep nginx 的输出里总是带着一条 grep nginx 进程本身。这是因为 grep 匹配到的内容包含了正在执行 grep 的那个进程。很多人习惯追加 grep -v grep 把它过滤掉，但更干净的做法是直接用 pgrep -af nginx，专门就是干这个的，还能直接拿到 PID。不过管道写法在面试和老系统里太常见，还是建议懂。
除了过滤进程，grep 配合 -C（上下文行数）在日志排障里非常有效：
bash复制# 查看包含 ERROR 的行，以及前后各 2 行
grep -C 2 "ERROR" /var/log/app.log
# 只看前面 3 行
grep -B 3 "ERROR" /var/log/app.log
# 只看后面 5 行
grep -A 5 "ERROR" /var/log/app.log
日志里报错信息前后几行往往藏着真正的异常栈，只看匹配行会错失关键上下文。
2.3 实战：三步找到“占空间的老日志”
把上面两个命令合起来，处理一个真