目前，只要敲几条命令，就能在几秒钟内把你要的文件找出来，不用翻目录、翻历史。把常用手法合成一个小脚本，输入关键词，按名字、按内容、按最近改动去搜，一起跑，结果并列出来，省心省力。
先说怎么用，效果最直观。把下面的内容存成可执行文件，给它传一个关键词，脚本会按三种方式并列查找，并且只把前面几条显示，避免信息淹没人眼力气。
脚本大致长这样：
#!/bin/bash
echo “=== 按文件名查找 ===”
find / -name “*$1*” 2>/dev/null
echo “”
echo “=== 按内容查找 ===”
grep -R “$1” / 2>/dev/null | head -20
echo “”
echo “=== 最近修改文件 ===”
find / -mmin -10 2>/dev/null
保存成 search.sh，给它执行权限后，像这样用：bash search.sh nginx。你会同时看到三个部分：名字里含 nginx 的文件、内容里带 nginx 的匹配（只显示前 20 条），还有最近 10 分钟内改过的文件。把这些线索放一起看，许多问题能很快被缩小到几处重点。
单项工具各有专长，知道怎么搭配更好用。遇到进程占端口或想看某程序打开了哪些文件，lsof 很管用。列如想知道 nginx 进程在用什么文件，先拿 PID，再传给 lsof：
sudo lsof -p $(pidof nginx)
或者直接看谁占了 80 端口：
sudo lsof -i :80
输出里会列出进程打开的文件句柄和网络连接，基于这些信息可以排端口冲突、确认是否加载了某个配置文件。注意，查看别人的进程信息一般需要 sudo 权限，没权限就别抱怨，得用管理员权限去看。
当系统出问题时，许多时候就是某个文件刚改过。find 可以按时间筛选出最近被改动的文件。列如查最近 10 分钟改过的文件：
find / -mmin -10
如果只关心 /etc 配置目录，想看 1 天内改过的：
find /etc -mtime -1
这类命令能把目光聚焦到“最近变动”的对象，减少排查范围。盘大的话别整盘找，加上 2>/dev/null 把权限错误的杂音丢掉。
如果你记得文件里有某些文字片段但忘了名字，grep 是最快的。递归搜索整个目录，找包含指定字符串的文件：
grep -R “error” /var/log
或者在 /etc 下找含端口 8080 的配置：
grep -R “8080” /etc
输出会包含匹配行和路径，看到哪儿有问题就能直接跳到对应文件看上下文。输出可能许多，配合 head、less、管道用起来更顺手。
按名字找文件就靠 find。根目录下名字带 nginx 的都列出来：
find / -name “*nginx*”
找某类文件也同理，列如把日志目录里所有 .log 列出来：
find /var/log -name “*.log”
按名字查直观、速度也还行（视搜索范围而定）。实战里把搜索目录限制住，别让整个盘都被翻，这样还能避免影响生产性能。
把这几招合在一起，实战效果好几倍提升。脚本里把按名字、按内容、按时间三路并列查，会从不同角度同时给出线索：名字线索、文件内容线索、时间线索。举个常见场景：服务器忽然响应慢，单看日志没发现明显错误，你跑脚本搜关键词 “timeout”。脚本告知你哪里日志里出现了 timeout，又指出有些配置文件最近被修改过。确认修改者后，再用 lsof 看哪个进程用了这些文件，结果发现某个服务重启后用了新配置，超时设置被触发。原本要一项项查可能得耗半天，用脚本并行查出来线索，跟着线索去验证，速度快许多。
说点实用的细节和坑，省得后面踩雷。全盘查会很慢，最好限定目录范围。grep -R 遍历大目录时会输出许多非文本文件的乱码或报错，把 stderr 丢掉或者只查文本文件更合适。权限不够会冒出一堆 “Permission denied”，要么 sudo，要么限定到你有权限的目录。lsof 输出信息多但杂，配 awk、grep 做简单过滤会干净点。find 的时间参数单位别弄混，-mmin -10 是查 10 分钟内，-mtime -1 是查 1 天内，记清楚别白忙。
执行脚本时，若只想看最相关的几行，可以把 grep 的输出截断，或者把 find 的结果按时间或路径长度排序。脚本只是最简单的组合，可以根据实际需求往里加逻辑：列如先执行 grep，若命中，就把对应文件的修改时间列出来；或者把 lsof 和 grep 结合，查出哪个进程在用某个日志文件，就直接去进程层面处理。再进一点，遇到输出太多的情况，用 awk 提取需要的列，把信息浓缩成能一眼看的样子。
有一次排查遇到奇怪的 502，团队里有人先盯着 nginx 配置，我当时直接跑了个脚本搜关键字 “502”。脚本把相关日志、带有 502 的请求记录，还有最近被改过的 upstream 配置都列出来。跟着线索去找修改记录，结果发现是某个自动部署脚本在凌晨拉了新镜像，但没更新 upstream 配置，导致转发异常。整个过程如果靠纯人工去翻日志、搜文件和看修改时间，效率低得不敢恭维；把常用查找合成脚本，初步线索出来后，接下来的验证和回滚都更清楚。
要是你常碰这种事，把常用查找整成一个脚本放到 PATH 里，起个短名字，平时输一个关键词就能跑三路搜索，节省不少来回切目录的时间。脚本不是灵丹妙药，但能把问题缩到几条可能的文件上，省时间、少折腾。还有别忘了在生产环境里限目录或在低峰期运行，避免把 IO 压垮。
最后一句实在的提议：工具得熟练用，遇事别慌，先把信息缩小到能处理的范围，再一步步核验。具体的命令和用法学起来不复杂，等你用上几次，就知道省了多少功夫。
暂无评论内容