1. 先别急着背命令清单把命令当成跟系统对话早些年我刚接触 Linux 命令的时候干过一件现在想起来有点好笑的事找了一份《常用 Linux 命令大全》把 ls、cd、cp、mv 的参数背得滚瓜烂熟结果到了真正需要排查问题的时候依然两眼一摸黑。后来真正让我对 Linux 命令开窍的不是某本速查手册而是一次在服务器上排查故障时的经历——我把一条一条看起来平平无奇的命令用管道串了起来突然意识到原来这些命令并不是一份需要死记硬背的清单它们本质上是一种向操作系统提问的方式。这篇文章不打算给你罗列几百条命令的用法我更想聊的是怎么把命令用起来怎么从一条单命令出发逐步组合成能解决实际问题的信息流水线排查服务器问题时应该按什么思路选择命令以及那些文档里通常不会写、但实战里特别关键的细节。适合刚学 Linux、总感觉命令学了就忘的新手也适合已经在日常使用 Linux、但遇到问题仍然不知道从何下手的进阶用户。1.1 命令是提问不是背诵清单我后来总结出一个观点每一条命令都在回答一个具体的问题。ls 回答这个目录里有什么ps 回答现在系统里有哪些进程在跑df 回答磁盘空间还剩多少。当你把命令理解成提问工具而不是要背的单词学习方式自然就变了——遇到陌生命令第一反应不再是我又要背一个了而是这条命令能帮我回答什么疑问。顺着这个思路命令后面的选项和参数也不过是让答案更精确的限定条件。比如 ps 这条命令ps aux 和 ps -ef 都能查看进程呢但输出格式不同适合的场景也不同。你不需要把几十个选项全部背下来只需要知道这条命令能回答进程状态这一类问题然后遇到实际需求时去查它的用法。查用法有两条路man 命令名或者 命令名 --help。很多人看到 man 手册那么长就退缩其实根本不需要从头读到尾只看你关心的那个选项就行。真正重要的不是把手册读完而是养成先查后试的习惯。这个习惯比任何命令大全都管用因为系统自带的帮助信息永远比别人的笔记更新、更贴合手头这个版本。1.2 从最小可运行命令开始别一上来就堆参数我见过不少人一上来就写特别长的命令比如 find 配合 -exec、多层管道、一堆选项全部叠加一旦报错根本不知道是哪一个环节出了问题。我的习惯刚好相反先跑一个最小版本确认命令本身能正常工作输出格式也符合预期然后再一点点把过滤条件、排序、统计加上去。这个过程很像排查电路故障先确认总闸有电再逐条支路检查而不是一上来就把所有开关都按一遍。举个例子你想用 awk 从日志里取某一列如果上来就写 awk {print $2}结果发现 $2 根本不是你想要的那一列因为你压根没见过日志原始长什么样。正确做法是先 head -n 5 日志文件看一眼列是怎么排的确认第几列是IP、第几列是时间再写 awk。这个先看输出、再动手处理的习惯能帮你省掉大量自我怀疑的时间。配套的技巧叫小范围验证处理大文件时先用 head 或 grep head 把输入缩小逻辑跑通之后再对全量数据执行。尤其是 sed、awk 这类会修改内容的命令强烈建议先在测试目录或小样本上试一遍确认结果符合预期再正式执行。别嫌这一步啰嗦真出问题的时候它会让你少说很多次完蛋了。这套方法同样适用于后面要讲的管道命令——每次只加一段跑一下确认没问题再继续拼。2. 一条排查命令是怎么长出来的管道组合实战很多人学命令是一条一条学的但实际干活的时候真正体现功力的地方是把命令用管道串起来。管道说白了就是把前一条命令的输出交给后一条命令作为输入。用好了一条命令就能完成一次小规模的数据分析。我拿一个特别常见的场景来讲某天服务响应变慢怀疑有客户端在反复刷某个接口日志目录里放着访问日志现在想找出到底哪些 IP 在频繁请求这个接口。2.1 场景与需求我要从日志里找到谁在刷接口先别急着写命令第一步是看一眼日志长什么样。执行 tail -n 20 访问日志路径确认列格式。这一步是整条排查命令的地基因为后面取哪一列、怎么过滤完全取决于日志里字段的排列方式。假设我们看到日志格式大致是IP 时间 请求方法 请求地址 状态码那 IP 就在第一列。很多人忽略这个步骤直接 grep 然后 awk {print $1}结果日志格式稍有变化取到的列根本不是自己想要的东西。这就是没看清现场就动手的典型失误。日志格式确认之后你的需求才能转成清晰的命令目标先过滤出包含指定接口的日志行再从这些行里提取 IP 字段最后按 IP 去重并统计请求次数。每一步对应什么命令这时就非常自然了。2.2 逐段拼接每加一步都验证一遍我按实际排查过程把这条命令拆开你可以看到它是怎么一步步长出来的。第一步只筛选出相关请求grep api/login 访问日志路径跑完先看输出是否符合预期如果行数太多可以先在末尾加 head -n 10 看几条样例。第二步把 IP 字段取出来grep api/login 访问日志路径 | awk {print $1}这时输出会是一堆可能重复的 IP。第三步排序并统计次数。这里有一个很关键的顺序问题必须先 sort 再 uniq -c。因为 uniq 默认只统计相邻的重复行如果同一个 IP 在文件中是分段出现的直接 uniq -c 会把一个 IP 统计成好几段结果完全错误。正确写法是grep api/login 访问日志路径 | awk {print $1} | sort | uniq -c到这一步输出变成次数 IP的形式。第四步按次数降序排列并只保留前 20 个结果grep api/login 访问日志路径 | awk {print $1} | sort | uniq -c | sort -rn | head -n 20看到这里你应该明白了这条命令不是背出来的而是从一个疑问出发通过不断验证中间输出自然组合出来的。每加一个管道段我都会先跑一遍看一眼输出内容是不是我想要的再决定下一步往哪边走。这种逐段验证的拼法比一口气写完长命令要可靠得多。2.3 组合管道时容易翻车的几个细节管道好用但有几个坑必须提醒。第一个坑是管道左侧失败右侧照跑。比如文件不存在时 grep 会报错但整个管道的退出状态取决于最后一个命令。如果你在脚本里启用了 set -e可能就不会因为文件不存在而中断脚本问题会被静默放过去后面拿到一堆错误数据时反而更难排查。第二个坑是隐藏字符。有些日志文件里带着 \r 回车符或者乱码输出看起来一切正常但 sort 和 uniq 的结果就是不符合预期。遇到可疑情况可以用 cat -A 文件名 | head 看一眼文件中是否藏着看不见的控制字符再决定要不要用 tr 或 sed 先清理。第三个坑是 awk 列号写死的问题。如果日志里大部分行有 7 列但偶尔几行因为格式异常只有 5 列取 $1 可能还算稳定取 $4 就可能错位。处理这类脏数据先分几行看一看字段结构差异再选择取列方式。我的建议是拼管道命令时每加一段就跑一遍确认中间结果正常再继续往后面接。这个习惯帮我在排错时节省了大量时间比任何命令速查表都实在。3. 资源状态排查进程、内存、磁盘的真实场景命令只有放到真实场景里反复用才会真正变成自己的东西。服务器出问题的时候其实是学习命令最好的机会。这一节我挑三个高频场景讲一下我是怎么看状态、怎么快速把问题定位到具体方向的。3.1 进程ps aux 只是起点/proc 里才是真正的细节ps aux 大家都会用但实际排查时有几个细节很容易被忽略。首先ps aux 默认按 PID 排序如果想找 CPU 或内存占用最高的进程要么用 sort 辅助要么进 top 再按对应列排序。其次ps aux 能看到进程的基本状态但看不到这个进程的完整启动命令、当前工作目录、环境变量以及它打开了哪些文件。这些细节要去 /proc/PID 目录里挖。比如某个进程 CPU 占用很高你想知道它到底在干什么可以先看 /proc/PID/cmdline 拿到完整的启动参数再看 /proc/PID/status 里的线程数和状态信息。如果怀疑进程打开了某个文件不释放可以用 lsof -p PID 查看它持有的文件句柄。说实话刚接触 Linux 的人会觉得 /proc 下一堆数字目录很怪但用熟了以后会发现它几乎是系统主动敞开的一扇观察窗口。补充一个实用命令想按内存占用排序找进程可以直接写 ps aux --sort-%mem | head -n 10一步到位。不过要提醒一点进程的 RSS 内存包含它加载的共享库占用的那部分把所有进程的 RSS 简单相加来估算系统总内存需求是不准确的这一点初学者非常容易误解。3.2 磁盘df 满了du 却找不到大文件磁盘满了但不知道是谁占的这个场景几乎每个运维和开发者都遇到过。df 和 du 的视角不一样df 看的是文件系统整体用了多少du 看的是某个目录下所有文件实际占用多少。如果 df -h 显示根分区已经 100%但到根目录执行 du -sh * 逐项相加后发现远小于总量说明一定有什么东西在看不见地占着空间。最常见的元凶有两个。第一个是已被删除但还被进程占用的文件进程打开了一个文件随后文件被删除但进程没有关闭句柄磁盘空间就不会释放。df 能看到空间没了du 却无论如何也找不到这个大文件。这种情况用 lsof | grep deleted 就能把它揪出来。第二个是 inode 耗尽小文件太多把索引节点用完了df 显示空间还有剩余但新文件就是创建不出来。这时候要执行 df -i 看 inode 使用率。很多人只盯 df -h不看 df -i所以遇到空间够但写不进文件这种诡异问题就会卡住。还有一种情况是目录被重复挂载。一个目录被挂到两个位置du 默认会跨挂载点重复计算导致统计结果虚高。如果只想看当前文件系统自己的用量给 du 加上 -x 参数让它不跨越文件系统边界。以后再遇到df 和 du 对不上时别急着怀疑命令先按这三条逐个排查思路会清楚很多。3.3 内存free 里的 buffer/cache 不是占用执行 free -h 的时候很多新手看到 used 很高、buff/cache 也很大就开始慌了觉得内存是不是快不够了。实际上buff/cache 是 Linux 的一种正常内存管理机制把暂时用不上的空闲内存拿去做文件缓存等应用程序需要更多内存时这些缓存会被随时释放回来。真正判断内存够不够要看的是 available 这一列它表示在不发生 swap 的情况下还能分配给新进程多少内存。判断内存压力的信号有这几个swap 使用率持续上涨、系统日志里出现 OOM 相关的记录、top 里某些进程被莫名其妙杀掉。遇到这些情况再去查到底是哪个进程占得多比直接升级内存更有效。我之前处理过类似场景一个服务平时内存占用正常但每到某个固定时间点就挂一次后来翻日志发现是定时任务和主服务同时跑内存峰值超标了。整个过程用到的命令也就是 free、top、journalctl 这些但核心在于是否愿意顺着现象多问几层为什么而不是停留在重启一下试试。4. 少跑冤枉路的排查思路从现象到根因命令只是工具思路决定你花多长时间解决问题。不少人在排查时喜欢病急乱投医这条命令不行换那条最后直接重启大法收场。其实只要按层次逐步排除很多问题都能在几分钟内锁定到很小的范围。这一节我想分享的是我在实际排错中沉淀下来的分层思考框架。4.1 先确认现象在哪一层再决定用什么命令一个服务访问不了可能性实际上非常多客户端 DNS 解析失败、网络不通、服务端口没监听、服务进程挂了、防火墙规则拦截、后端数据库连不上、应用代码本身报错。如果一上来就 ping 网关很可能把时间浪费在错误的方向上。我的习惯是把问题分四层看应用层、传输层、网络层、系统层按顺序逐层验证。第一层先在服务器本机测应用层用 curl 访问本机地址如果服务本身和端口都正常curl 应该很快返回业务响应。第二层从内网或外部机器访问看是不是网络路径或防火墙拦截的问题。第三层查服务日志确认是业务逻辑报错还是资源不足。每一层都用一两个命令去验证然后缩小范围。比如 curl 本机通、外部不通问题大概率在网络层或防火墙本机 curl 都不通那就直接往进程和端口方向查。这套思路听着简单但实际很多人遇到问题的第一个动作就是重启服务。重启确实能让问题暂时消失但也会把现场破坏掉——进程状态、网络连接、日志上下文全部重置之后再想复盘根因就非常被动了。我的原则是重启之前至少先保存日志、记录进程状态、记下时间线这三样东西。保住现场比急着恢复服务更有利于找到真因。4.2 网络类命令的高频组合与正确用法网络排查的命令本身不难难的是理解每一条命令到底能证明什么。ping 通了只能说明 ICMP 这一层通不能证明业务端口是通的端口能连上说明 TCP 握手成功但也不代表应用层正常。所以我常用的组合是先 ping 看基础连通性再 ss -tlnp 看本机端口是否在监听然后用 nc 从另一端测一下端口连通性最后用 curl -v 带超时参数去测应用层响应。每一条命令回答的层都不同组合起来才能完成定位。举一个实际的排查过程某次遇到网站间歇性打不开我在服务器本机用 curl 访问一切正常但从外部访问就超时。接下来用 nc -vz 目标IP 端口 测端口发现 TCP 层也通不过于是基本判断问题出在网络路径或防火墙。再检查防火墙规则和安全组配置很快就找到了原因。全程没有用任何复杂的命令但每一条都完成了排除一个方向的任务。这里有个容易被忽略的细节nc、mtr、dig 这类命令在部分精简安装的 Linux 上默认不存在。在网络问题排查之前先确认系统里有没有这些工具缺什么就装什么否则查了半天才发现命令根本不存在节奏就被完全打乱了。另外curl 的 -w 参数可以输出连接耗时、总时间等指标用来判断慢在哪一段尤其好用值得专门花两分钟熟悉一下。4.3 日志时间线别只盯着最新几行日志是排查问题最直接的现场记录但很多人只会 tail -n 100 看最近几行。问题如果发生在几小时前等你发现并登录服务器的时候关键日志可能早就被新内容冲掉了。正确的做法是先确定问题是从什么时候开始出现的然后把那个时间窗口附近的日志完整拉出来看。目前我用的比较多的方式是 journalctl 这套执行 journalctl -u 服务名 --since 2 hours ago 可以看某个服务最近两个小时的日志还能用 --until 进一步收窄时间窗口。接着用 grep 按关键词过滤比如搜 OOM、error、timeout然后再顺着时间线把上下文完整看一遍。很多时候真正的根因藏在错误日志前面几十行里只看孤零零的一句报错很容易被误导到错误的方向。如果系统没有启用 journalctl日志只写在传统文件里可以先看日志文件的修改时间来判断问题的大致时间点再从那个时间点附近取日志。无论用哪种方式核心方法是一致的把错误发生时刻前后几分钟的信息放到一起看。排查问题要看时间线而不是只看单个报错点这是我跟很多人反复强调的一点。5. 被默认忽略的命令习惯安全与效率兼得最后想聊的是命令使用习惯。这部分很少有人专门教但踩过的坑往往最疼。我总结了几条可以直接照做的经验能帮你少走很多弯路。5.1 rm 这类危险操作给自己上个保险rm -rf 是很多人心中的噩梦。最常见的风险来源是这几个路径变量为空、路径拼写错误、在错误的目录下执行。我的建议有三条。第一把 rm 替换成带回收站功能的方式比如设置 alias rmtrash-put或者写一个自定义函数把删除的文件移动到一个专门的回收目录里这样至少还有后悔药可以吃。第二如果必须在脚本里用 rm先判断变量是否为非空比如 [[ -n $目录变量 ]] 确认后再继续操作。第三执行删除之前先 pwd 确认当前目录再 ls 确认目标路径。有人觉得这些习惯太啰嗦但真出过一次事就会明白多花十秒钟确认比花一整晚恢复数据划算太多。尤其是在生产环境里rm 的安全习惯应该变成肌肉记忆不靠运气靠流程。5.2 history、alias、配置把常用命令沉淀成自己的装备命令用好之后很多人还是每次重复敲一长串效率很低。我习惯把高频组合写成别名比如 alias llls -lh、alias ggrep、alias ..cd ..写进 ~/.bashrc 或 ~/.zshrc 之后日常操作会舒服很多。但这里有一个经典坑要提醒在脚本里不要依赖别名。非交互式 shell 默认不会展开 alias你明明配置了 alias ggrep在脚本里写 g abc file 却可能报命令找不到这个问题会让不少人困惑很久。历史记录也值得好好配置。默认情况下 history 只记录命令本身不记录时间长度也有限。我通常会在配置里加这几行HISTTIMEFORMAT%F %T HISTSIZE10000 HISTFILESIZE20000加上之后history 输出会带上时间戳复盘问题的时候会非常有用。还有一条安全习惯必须强调不要把密码、密钥、token 直接写在命令行里因为 history 会记录脚本里也会留痕。如果确实需要应该通过环境变量或配置文件读取不要图省事直接明文写在命令里。5.3 重定向、通配符、sudo 的常见坑重定向是新手最容易出问题的地方。第一点是 会覆盖文件 会追加文件第二点是 21 表示把标准错误重定向到标准输出当前指向的位置这两者顺序不同结果也完全不同。一个非常经典的错误是执行 sudo echo 1 /某个root属主的文件结果报权限不足因为重定向是当前 shell 打开的sudo 只作用于 echo 命令本身。正确做法是 echo 1 | sudo tee /某个root属主的文件或者 sudo bash -c echo 1 /某个root属主的文件。通配符也有一个容易踩的坑。rm.log 在没有匹配文件时.log 这个字面字符串会原样传给 rm然后 rm 报错文件不存在。更危险的情况是如果目录里恰好有一个文件叫 *.log这个命令会把它也删掉。要避免这类意外可以写 rm -- *.log双横线表示后面的参数都作为文件名处理。通配符本质上是 shell 先做展开再交给命令执行理解了这个机制你才能控制它而不是被它坑到。最后说一句 sudo 的使用边界。很多人习惯遇到权限问题就一长串 sudo但这会掩盖真实的权限问题。能用普通用户执行就不要用 root 身份能限制在单条命令上就不要开一个 root shell。这句话听起来像老生常谈但生产环境里权限最小化是真的能兜底的。根据自己的经验我最后分享一个小习惯每周挑一条平时用得少但知道很有用的命令比如 find、xargs、jq花十分钟读一遍它的手册在一个测试目录里用真实数据玩一遍然后思考它还能怎么跟别的命令组合。坚持一个月你会发现自己能写出来的命令结构越来越丰富。Linux 命令这东西背了不用等于没学用了并且认真思考过才真正变成你自己的。 
长河君 · 2026/10/20 3:04:52 · 阅读 1.2k Linux命令实战：从管道组合到服务器故障排查指南
1. 先别急着背命令清单把命令当成跟系统对话早些年我刚接触 Linux 命令的时候干过一件现在想起来有点好笑的事找了一份《常用 Linux 命令大全》把 ls、cd、cp、mv 的参数背得滚瓜烂熟结果到了真正需要排查问题的时候依然两眼一摸黑。后来真正让我对 Linux 命令开窍的不是某本速查手册而是一次在服务器上排查故障时的经历——我把一条一条看起来平平无奇的命令用管道串了起来突然意识到原来这些命令并不是一份需要死记硬背的清单它们本质上是一种向操作系统提问的方式。这篇文章不打算给你罗列几百条命令的用法我更想聊的是怎么把命令用起来怎么从一条单命令出发逐步组合成能解决实际问题的信息流水线排查服务器问题时应该按什么思路选择命令以及那些文档里通常不会写、但实战里特别关键的细节。适合刚学 Linux、总感觉命令学了就忘的新手也适合已经在日常使用 Linux、但遇到问题仍然不知道从何下手的进阶用户。1.1 命令是提问不是背诵清单我后来总结出一个观点每一条命令都在回答一个具体的问题。ls 回答这个目录里有什么ps 回答现在系统里有哪些进程在跑df 回答磁盘空间还剩多少。当你把命令理解成提问工具而不是要背的单词学习方式自然就变了——遇到陌生命令第一反应不再是我又要背一个了而是这条命令能帮我回答什么疑问。顺着这个思路命令后面的选项和参数也不过是让答案更精确的限定条件。比如 ps 这条命令ps aux 和 ps -ef 都能查看进程呢但输出格式不同适合的场景也不同。你不需要把几十个选项全部背下来只需要知道这条命令能回答进程状态这一类问题然后遇到实际需求时去查它的用法。查用法有两条路man 命令名或者 命令名 --help。很多人看到 man 手册那么长就退缩其实根本不需要从头读到尾只看你关心的那个选项就行。真正重要的不是把手册读完而是养成先查后试的习惯。这个习惯比任何命令大全都管用因为系统自带的帮助信息永远比别人的笔记更新、更贴合手头这个版本。1.2 从最小可运行命令开始别一上来就堆参数我见过不少人一上来就写特别长的命令比如 find 配合 -exec、多层管道、一堆选项全部叠加一旦报错根本不知道是哪一个环节出了问题。我的习惯刚好相反先跑一个最小版本确认命令本身能正常工作输出格式也符合预期然后再一点点把过滤条件、排序、统计加上去。这个过程很像排查电路故障先确认总闸有电再逐条支路检查而不是一上来就把所有开关都按一遍。举个例子你想用 awk 从日志里取某一列如果上来就写 awk {print $2}结果发现 $2 根本不是你想要的那一列因为你压根没见过日志原始长什么样。正确做法是先 head -n 5 日志文件看一眼列是怎么排的确认第几列是IP、第几列是时间再写 awk。这个先看输出、再动手处理的习惯能帮你省掉大量自我怀疑的时间。配套的技巧叫小范围验证处理大文件时先用 head 或 grep head 把输入缩小逻辑跑通之后再对全量数据执行。尤其是 sed、awk 这类会修改内容的命令强烈建议先在测试目录或小样本上试一遍确认结果符合预期再正式执行。别嫌这一步啰嗦真出问题的时候它会让你少说很多次完蛋了。这套方法同样适用于后面要讲的管道命令——每次只加一段跑一下确认没问题再继续拼。2. 一条排查命令是怎么长出来的管道组合实战很多人学命令是一条一条学的但实际干活的时候真正体现功力的地方是把命令用管道串起来。管道说白了就是把前一条命令的输出交给后一条命令作为输入。用好了一条命令就能完成一次小规模的数据分析。我拿一个特别常见的场景来讲某天服务响应变慢怀疑有客户端在反复刷某个接口日志目录里放着访问日志现在想找出到底哪些 IP 在频繁请求这个接口。2.1 场景与需求我要从日志里找到谁在刷接口先别急着写命令第一步是看一眼日志长什么样。执行 tail -n 20 访问日志路径确认列格式。这一步是整条排查命令的地基因为后面取哪一列、怎么过滤完全取决于日志里字段的排列方式。假设我们看到日志格式大致是IP 时间 请求方法 请求地址 状态码那 IP 就在第一列。很多人忽略这个步骤直接 grep 然后 awk {print $1}结果日志格式稍有变化取到的列根本不是自己想要的东西。这就是没看清现场就动手的典型失误。日志格式确认之后你的需求才能转成清晰的命令目标先过滤出包含指定接口的日志行再从这些行里提取 IP 字段最后按 IP 去重并统计请求次数。每一步对应什么命令这时就非常自然了。2.2 逐段拼接每加一步都验证一遍我按实际排查过程把这条命令拆开你可以看到它是怎么一步步长出来的。第一步只筛选出相关请求grep api/login 访问日志路径跑完先看输出是否符合预期如果行数太多可以先在末尾加 head -n 10 看几条样例。第二步把 IP 字段取出来grep api/login 访问日志路径 | awk {print $1}这时输出会是一堆可能重复的 IP。第三步排序并统计次数。这里有一个很关键的顺序问题必须先 sort 再 uniq -c。因为 uniq 默认只统计相邻的重复行如果同一个 IP 在文件中是分段出现的直接 uniq -c 会把一个 IP 统计成好几段结果完全错误。正确写法是grep api/login 访问日志路径 | awk {print $1} | sort | uniq -c到这一步输出变成次数 IP的形式。第四步按次数降序排列并只保留前 20 个结果grep api/login 访问日志路径 | awk {print $1} | sort | uniq -c | sort -rn | head -n 20看到这里你应该明白了这条命令不是背出来的而是从一个疑问出发通过不断验证中间输出自然组合出来的。每加一个管道段我都会先跑一遍看一眼输出内容是不是我想要的再决定下一步往哪边走。这种逐段验证的拼法比一口气写完长命令要可靠得多。2.3 组合管道时容易翻车的几个细节管道好用但有几个坑必须提醒。第一个坑是管道左侧失败右侧照跑。比如文件不存在时 grep 会报错但整个管道的退出状态取决于最后一个命令。如果你在脚本里启用了 set -e可能就不会因为文件不存在而中断脚本问题会被静默放过去后面拿到一堆错误数据时反而更难排查。第二个坑是隐藏字符。有些日志文件里带着 \r 回车符或者乱码输出看起来一切正常但 sort 和 uniq 的结果就是不符合预期。遇到可疑情况可以用 cat -A 文件名 | head 看一眼文件中是否藏着看不见的控制字符再决定要不要用 tr 或 sed 先清理。第三个坑是 awk 列号写死的问题。如果日志里大部分行有 7 列但偶尔几行因为格式异常只有 5 列取 $1 可能还算稳定取 $4 就可能错位。处理这类脏数据先分几行看一看字段结构差异再选择取列方式。我的建议是拼管道命令时每加一段就跑一遍确认中间结果正常再继续往后面接。这个习惯帮我在排错时节省了大量时间比任何命令速查表都实在。3. 资源状态排查进程、内存、磁盘的真实场景命令只有放到真实场景里反复用才会真正变成自己的东西。服务器出问题的时候其实是学习命令最好的机会。这一节我挑三个高频场景讲一下我是怎么看状态、怎么快速把问题定位到具体方向的。3.1 进程ps aux 只是起点/proc 里才是真正的细节ps aux 大家都会用但实际排查时有几个细节很容易被忽略。首先ps aux 默认按 PID 排序如果想找 CPU 或内存占用最高的进程要么用 sort 辅助要么进 top 再按对应列排序。其次ps aux 能看到进程的基本状态但看不到这个进程的完整启动命令、当前工作目录、环境变量以及它打开了哪些文件。这些细节要去 /proc/PID 目录里挖。比如某个进程 CPU 占用很高你想知道它到底在干什么可以先看 /proc/PID/cmdline 拿到完整的启动参数再看 /proc/PID/status 里的线程数和状态信息。如果怀疑进程打开了某个文件不释放可以用 lsof -p PID 查看它持有的文件句柄。说实话刚接触 Linux 的人会觉得 /proc 下一堆数字目录很怪但用熟了以后会发现它几乎是系统主动敞开的一扇观察窗口。补充一个实用命令想按内存占用排序找进程可以直接写 ps aux --sort-%mem | head -n 10一步到位。不过要提醒一点进程的 RSS 内存包含它加载的共享库占用的那部分把所有进程的 RSS 简单相加来估算系统总内存需求是不准确的这一点初学者非常容易误解。3.2 磁盘df 满了du 却找不到大文件磁盘满了但不知道是谁占的这个场景几乎每个运维和开发者都遇到过。df 和 du 的视角不一样df 看的是文件系统整体用了多少du 看的是某个目录下所有文件实际占用多少。如果 df -h 显示根分区已经 100%但到根目录执行 du -sh * 逐项相加后发现远小于总量说明一定有什么东西在看不见地占着空间。最常见的元凶有两个。第一个是已被删除但还被进程占用的文件进程打开了一个文件随后文件被删除但进程没有关闭句柄磁盘空间就不会释放。df 能看到空间没了du 却无论如何也找不到这个大文件。这种情况用 lsof | grep deleted 就能把它揪出来。第二个是 inode 耗尽小文件太多把索引节点用完了df 显示空间还有剩余但新文件就是创建不出来。这时候要执行 df -i 看 inode 使用率。很多人只盯 df -h不看 df -i所以遇到空间够但写不进文件这种诡异问题就会卡住。还有一种情况是目录被重复挂载。一个目录被挂到两个位置du 默认会跨挂载点重复计算导致统计结果虚高。如果只想看当前文件系统自己的用量给 du 加上 -x 参数让它不跨越文件系统边界。以后再遇到df 和 du 对不上时别急着怀疑命令先按这三条逐个排查思路会清楚很多。3.3 内存free 里的 buffer/cache 不是占用执行 free -h 的时候很多新手看到 used 很高、buff/cache 也很大就开始慌了觉得内存是不是快不够了。实际上buff/cache 是 Linux 的一种正常内存管理机制把暂时用不上的空闲内存拿去做文件缓存等应用程序需要更多内存时这些缓存会被随时释放回来。真正判断内存够不够要看的是 available 这一列它表示在不发生 swap 的情况下还能分配给新进程多少内存。判断内存压力的信号有这几个swap 使用率持续上涨、系统日志里出现 OOM 相关的记录、top 里某些进程被莫名其妙杀掉。遇到这些情况再去查到底是哪个进程占得多比直接升级内存更有效。我之前处理过类似场景一个服务平时内存占用正常但每到某个固定时间点就挂一次后来翻日志发现是定时任务和主服务同时跑内存峰值超标了。整个过程用到的命令也就是 free、top、journalctl 这些但核心在于是否愿意顺着现象多问几层为什么而不是停留在重启一下试试。4. 少跑冤枉路的排查思路从现象到根因命令只是工具思路决定你花多长时间解决问题。不少人在排查时喜欢病急乱投医这条命令不行换那条最后直接重启大法收场。其实只要按层次逐步排除很多问题都能在几分钟内锁定到很小的范围。这一节我想分享的是我在实际排错中沉淀下来的分层思考框架。4.1 先确认现象在哪一层再决定用什么命令一个服务访问不了可能性实际上非常多客户端 DNS 解析失败、网络不通、服务端口没监听、服务进程挂了、防火墙规则拦截、后端数据库连不上、应用代码本身报错。如果一上来就 ping 网关很可能把时间浪费在错误的方向上。我的习惯是把问题分四层看应用层、传输层、网络层、系统层按顺序逐层验证。第一层先在服务器本机测应用层用 curl 访问本机地址如果服务本身和端口都正常curl 应该很快返回业务响应。第二层从内网或外部机器访问看是不是网络路径或防火墙拦截的问题。第三层查服务日志确认是业务逻辑报错还是资源不足。每一层都用一两个命令去验证然后缩小范围。比如 curl 本机通、外部不通问题大概率在网络层或防火墙本机 curl 都不通那就直接往进程和端口方向查。这套思路听着简单但实际很多人遇到问题的第一个动作就是重启服务。重启确实能让问题暂时消失但也会把现场破坏掉——进程状态、网络连接、日志上下文全部重置之后再想复盘根因就非常被动了。我的原则是重启之前至少先保存日志、记录进程状态、记下时间线这三样东西。保住现场比急着恢复服务更有利于找到真因。4.2 网络类命令的高频组合与正确用法网络排查的命令本身不难难的是理解每一条命令到底能证明什么。ping 通了只能说明 ICMP 这一层通不能证明业务端口是通的端口能连上说明 TCP 握手成功但也不代表应用层正常。所以我常用的组合是先 ping 看基础连通性再 ss -tlnp 看本机端口是否在监听然后用 nc 从另一端测一下端口连通性最后用 curl -v 带超时参数去测应用层响应。每一条命令回答的层都不同组合起来才能完成定位。举一个实际的排查过程某次遇到网站间歇性打不开我在服务器本机用 curl 访问一切正常但从外部访问就超时。接下来用 nc -vz 目标IP 端口 测端口发现 TCP 层也通不过于是基本判断问题出在网络路径或防火墙。再检查防火墙规则和安全组配置很快就找到了原因。全程没有用任何复杂的命令但每一条都完成了排除一个方向的任务。这里有个容易被忽略的细节nc、mtr、dig 这类命令在部分精简安装的 Linux 上默认不存在。在网络问题排查之前先确认系统里有没有这些工具缺什么就装什么否则查了半天才发现命令根本不存在节奏就被完全打乱了。另外curl 的 -w 参数可以输出连接耗时、总时间等指标用来判断慢在哪一段尤其好用值得专门花两分钟熟悉一下。4.3 日志时间线别只盯着最新几行日志是排查问题最直接的现场记录但很多人只会 tail -n 100 看最近几行。问题如果发生在几小时前等你发现并登录服务器的时候关键日志可能早就被新内容冲掉了。正确的做法是先确定问题是从什么时候开始出现的然后把那个时间窗口附近的日志完整拉出来看。目前我用的比较多的方式是 journalctl 这套执行 journalctl -u 服务名 --since 2 hours ago 可以看某个服务最近两个小时的日志还能用 --until 进一步收窄时间窗口。接着用 grep 按关键词过滤比如搜 OOM、error、timeout然后再顺着时间线把上下文完整看一遍。很多时候真正的根因藏在错误日志前面几十行里只看孤零零的一句报错很容易被误导到错误的方向。如果系统没有启用 journalctl日志只写在传统文件里可以先看日志文件的修改时间来判断问题的大致时间点再从那个时间点附近取日志。无论用哪种方式核心方法是一致的把错误发生时刻前后几分钟的信息放到一起看。排查问题要看时间线而不是只看单个报错点这是我跟很多人反复强调的一点。5. 被默认忽略的命令习惯安全与效率兼得最后想聊的是命令使用习惯。这部分很少有人专门教但踩过的坑往往最疼。我总结了几条可以直接照做的经验能帮你少走很多弯路。5.1 rm 这类危险操作给自己上个保险rm -rf 是很多人心中的噩梦。最常见的风险来源是这几个路径变量为空、路径拼写错误、在错误的目录下执行。我的建议有三条。第一把 rm 替换成带回收站功能的方式比如设置 alias rmtrash-put或者写一个自定义函数把删除的文件移动到一个专门的回收目录里这样至少还有后悔药可以吃。第二如果必须在脚本里用 rm先判断变量是否为非空比如 [[ -n $目录变量 ]] 确认后再继续操作。第三执行删除之前先 pwd 确认当前目录再 ls 确认目标路径。有人觉得这些习惯太啰嗦但真出过一次事就会明白多花十秒钟确认比花一整晚恢复数据划算太多。尤其是在生产环境里rm 的安全习惯应该变成肌肉记忆不靠运气靠流程。5.2 history、alias、配置把常用命令沉淀成自己的装备命令用好之后很多人还是每次重复敲一长串效率很低。我习惯把高频组合写成别名比如 alias llls -lh、alias ggrep、alias ..cd ..写进 ~/.bashrc 或 ~/.zshrc 之后日常操作会舒服很多。但这里有一个经典坑要提醒在脚本里不要依赖别名。非交互式 shell 默认不会展开 alias你明明配置了 alias ggrep在脚本里写 g abc file 却可能报命令找不到这个问题会让不少人困惑很久。历史记录也值得好好配置。默认情况下 history 只记录命令本身不记录时间长度也有限。我通常会在配置里加这几行HISTTIMEFORMAT%F %T HISTSIZE10000 HISTFILESIZE20000加上之后history 输出会带上时间戳复盘问题的时候会非常有用。还有一条安全习惯必须强调不要把密码、密钥、token 直接写在命令行里因为 history 会记录脚本里也会留痕。如果确实需要应该通过环境变量或配置文件读取不要图省事直接明文写在命令里。5.3 重定向、通配符、sudo 的常见坑重定向是新手最容易出问题的地方。第一点是 会覆盖文件 会追加文件第二点是 21 表示把标准错误重定向到标准输出当前指向的位置这两者顺序不同结果也完全不同。一个非常经典的错误是执行 sudo echo 1 /某个root属主的文件结果报权限不足因为重定向是当前 shell 打开的sudo 只作用于 echo 命令本身。正确做法是 echo 1 | sudo tee /某个root属主的文件或者 sudo bash -c echo 1 /某个root属主的文件。通配符也有一个容易踩的坑。rm.log 在没有匹配文件时.log 这个字面字符串会原样传给 rm然后 rm 报错文件不存在。更危险的情况是如果目录里恰好有一个文件叫 *.log这个命令会把它也删掉。要避免这类意外可以写 rm -- *.log双横线表示后面的参数都作为文件名处理。通配符本质上是 shell 先做展开再交给命令执行理解了这个机制你才能控制它而不是被它坑到。最后说一句 sudo 的使用边界。很多人习惯遇到权限问题就一长串 sudo但这会掩盖真实的权限问题。能用普通用户执行就不要用 root 身份能限制在单条命令上就不要开一个 root shell。这句话听起来像老生常谈但生产环境里权限最小化是真的能兜底的。根据自己的经验我最后分享一个小习惯每周挑一条平时用得少但知道很有用的命令比如 find、xargs、jq花十分钟读一遍它的手册在一个测试目录里用真实数据玩一遍然后思考它还能怎么跟别的命令组合。坚持一个月你会发现自己能写出来的命令结构越来越丰富。Linux 命令这东西背了不用等于没学用了并且认真思考过才真正变成你自己的。