说实话这年头谁电脑里没存过几张“Linux 常用命令大全”的截图我自己从刚入行那会儿就开始收集这类速查表手机上存过、书签里收藏过、笔记软件里记过。后来发现一个问题收藏从不等于掌握。速查表真正的作用不是让你背下来而是在关键时刻替你省下翻文档的那几分钟尤其是线上出故障、领导站在背后、业务方在群里连环催的时候。今天分享的这份分类速查表是我这几年把它当成“桌面工具”用的版本。它不是教科书式的命令罗列而是按日常干活的实际场景来分类——文件操作、日志排查、网络诊断、容器管理、面试突击每一类都配了使用场景和常见的坑。无论你是刚接触 Linux 的新手还是想系统梳理一遍命令体系的运维、开发这篇文章应该都能让你有点收获。1. 速查表不是背出来的先搞懂命令的本质1.1 命令只是工具不是知识我见过太多人学 Linux 命令的方式买了一本六七百页的《Linux 命令大全》从第一页开始背背到ls的十七种参数就放弃了。这是典型的把工具当知识在学方向完全反了。命令的本质是工具就像螺丝刀和扳手你不需要背下每种螺丝刀的型号你只需要知道“拧十字螺丝用十字头拧内六角用内六角扳手”然后在你真的需要拧螺丝的时候知道去哪把找那把对的工具。Linux 命令也一样ls、cd、cat这些高频命令用几次就肌肉记忆了traceroute、iostat这种低频命令你只需要知道“排查网络延迟用它”“排查磁盘 IO 用它”到了现场再man一下或者查下速查表就行。所以这份速查表的第一个设计原则是按场景分类不按字母排序。字母排序适合字典不适合干活。真正干活的时候你的脑子里想的是“我要看日志的最新内容”而不是“我要找一个 L 开头的命令”。1.2 我推荐的三层分类法用了这么多年我把 Linux 命令分成三层对应不同的使用频率和掌握程度第一层肌肉层命令。每天都要敲的比如ls、cd、cat、grep、ps、df。这类命令不需要看速查表敲多了自然熟目标是形成肌肉记忆。第二层场景层命令。平时用不到但一到特定场景就特别重要比如排查网络时的traceroute、分析磁盘 IO 的iostat、批量改文本的sed。这类命令适合做成速查表用时快速定位。第三层专家层命令。比如gdb调试、perf性能分析、strace系统调用跟踪。这类命令有很高的学习曲线用之前需要先了解背景知识速查表只能起到“提词器”的作用。你只需要把第一层练熟第二层做好索引第三层知道有这个东西且能看懂基本输出就行。下面我按这个思路把常用命令分类展开。2. 文件与文本处理每天敲得最多的命令族2.1 文件查看从 cat 到 tail -f 的进化很多人对文件查看的理解停留在catcat确实能把整个文件内容怼到屏幕上但它有两个问题一是文件一大终端刷屏刷到你怀疑人生二是你根本没法定位到想看的位置。所以我的建议是小文件用cat大文件用less跟踪日志用tail -f。less是我最推荐的文件查看工具它支持上下翻页、搜索关键字、跳转到指定行。打开一个几百 MB 的日志文件less秒开cat能把终端卡死。常用的操作/关键字往下搜?关键字往上搜g跳到文件头G跳到文件尾q退出。这几个键记住基本就可以扔掉cat了。tail -f是排查日志的利器-f的意思是 follow实时跟踪文件末尾新增的内容。当你在排线上 bug需要盯着日志看输出时tail -f app.log就是你的主战场。如果只想看最后 100 行tail -100 app.log。反过来如果文件不大但想看开头部分head -50 app.log。这里插一个我踩过的坑用tail -f看日志终端挂着不动你以为程序挂了其实是因为日志写得太慢或者你打开的日志文件根本没有新内容写入。这时候先确认文件有没有在增长用ls -l看文件大小或者加个-n 0参数直接从当前尾部开始跟踪。2.2 搜索与统计grep、find、awk 的组合玩法grep是 Linux 里使用率前三的命令它的核心功能是在文件内容里搜关键字但很多人只会grep xxx file。实际工作中我几乎总是搭配参数使用grep -i keyword file忽略大小写搜日志的时候尤其有用因为你不知道应用是输出Error还是ERROR。grep -v keyword file反向匹配过滤掉含关键字的行相当于“排除法”。grep -n keyword file显示行号定位到具体的位置方便去源码里查。grep -r keyword /path/to/dir递归搜索整个目录适合在项目代码里找关键字。grep -c keyword file统计匹配的行数不显示内容适合统计错误数量。比如排查接口报错直接grep -c Exception app.log看有多少次异常。find是另一个高频命令它是按文件名、大小、时间等条件在目录树里找文件。比如find / -name nginx.conf 2/dev/null全局找文件名2/dev/null把权限报错丢进黑洞。find /data -mtime -3查找最近 3 天内修改过的文件排查“谁动了我的服务器”时很有用。find /data -type f -size 100M找大于 100MB 的文件清理磁盘时必备。至于awk这是一个能让你从“会 Linux”进阶到“懂文本处理”的命令。它的核心是按列处理文本。比如日志格式是“时间 IP 状态码 耗时”你想提取所有耗时超过 3 秒的请求 IP一条awk就能搞定。我常用的是awk {print $1, $4}这种提取列的用法配合sort | uniq -c还能做简单的统计排序。不过awk的语法需要单独学习速查表里先记住两个最常用的awk {print $N}取第 N 列awk -F, {print $1}指定分隔符取列。2.3 修改与编辑sed 和 vim 的实用片段如果有人问我服务器上改文件用什么我的答案是sed。sed是流编辑器非常适合做批量的、非交互式的文本替换。比如sed -i s/old_string/new_string/g config.conf这条命令把config.conf里所有old_string替换成new_string-i表示直接修改文件g表示全局替换。这在批量改配置文件时是救命稻草。比如你有 10 台服务器要统一把 Redis 密码从oldpass改成newpass用sed -i配合一个循环脚本几分钟就能搞定。vim则适合交互式编辑。我理解很多人一进vim就手足无措只记住两个模式按i进入编辑模式按Esc退出编辑模式然后输入:wq保存退出。再记一个:q!强制不保存退出这基本就能活下来了。如果非要再记一个dd可以删除整行在vim里修改配置时非常好用。提示sed -i是直接改文件的执行前建议先备份。我习惯写成sed -i.bak s/xxx/yyy/g file这样会自动生成一个file.bak备份文件。线上配置改坏了还能一秒回滚。3. 运维排查六板斧日志、进程、网络、磁盘一次说清3.1 日志定位tail、less、journalctl 怎么配合排查线上问题第一步永远是看日志。我的固定套路是先确认日志文件在哪。应用自己定义的一般在/var/log/下或者应用目录的logs/文件夹systemd 管理的服务用journalctl -u 服务名。tail -n 100 app.log看最近报错。如果报错信息不够完整用grep -n Exception app.log | head定位最早出现异常的位置再sed -n 1200,1220p app.log看指定行区间的上下文。比如你用journalctl查一个服务journalctl -u nginx --since today --until 2024-01-01 12:00:00这就是查 systemd 管理的 nginx 服务今天的日志。在看不到日志文件路径的 CentOS 7 系统里这个命令是绕不开的。3.2 进程与负载ps、top、htop 的快速判断“机器卡了”是运维接收到最多的反馈但“卡”是一个模糊描述有可能是 CPU 满、内存不足、磁盘 IO 瓶颈甚至网络带宽打满。我的排查顺序是先top看整体负载再ps看具体进程。top默认每 3 秒刷新一次按P按 CPU 排序按M按内存排序。第一眼要看的三个数load average1、5、15 分钟的平均负载、%Cpu(s)里us用户态和wa等待 IO的占比、KiB Mem里 available 是否远小于 total。如果 load average 超过 CPU 核数说明系统在排队大概率有进程在打满资源。此时按P让 CPU 占用率最高的进程排到最上面记下 PID再用ps aux | grep PID看这个进程的详细信息包括启动命令、所属用户、启动时间。htop是top的增强版有颜色、可点击、支持树状视图但很多精简版系统默认没装。我的习惯是先top快速判断再htop深入分析。如果你有台机器没装htoptop也完全可以胜任 80% 的排查场景。3.3 网络与端口netstat、ss、curl 排障实录“服务起不来”“端口不通”“访问超时”这类问题靠网络排查命令解决。我常用的三件套是ss、curl、ping。ss是netstat的替代品输出更快更清晰。查某个端口是否在监听ss -lntp | grep 8080-l只显示监听状态的端口-n不解析域名和用户名显示数字-t只显示 TCP 连接-p显示进程信息如果你发现端口没监听说明服务可能挂了如果端口是LISTEN状态但你仍然连不上那就要考虑防火墙了。CentOS 7 检查防火墙用firewall-cmd --list-allUbuntu 用ufw status。curl是我测试 HTTP 接口最常用的工具它能模拟请求并返回响应curl -I http://localhost:8080 curl -v http://localhost:8080/api/health-I只显示响应头-v显示详细过程包括 DNS 解析、TCP 连接、TLS 握手、请求头和响应体。当你需要排查“为什么请求失败”curl -v能告诉你卡在哪一步DNS 解析失败、连接被拒、超时、还是 TLS 证书有问题。3.4 磁盘与存储df、du、lsblk 的容量排查磁盘满是个经典故障表现是服务突然写不了日志、数据库报错“no space left on device”。排查命令很简单df -h看文件系统使用率du -sh看某个目录占了多少空间。df -h du -sh /var/log/*df -h输出里你会看到若干行找到挂载点/的那一行Use% 接近 100% 就是根分区满了。接下来用du -sh /var/log/*找一下是哪个子目录占了大头比如发现messages日志文件已经 20GB那就确认是日志没做轮转直接处理。lsblk则是看磁盘分区的命令输出很直观能看清整块磁盘分成几个分区、挂载到哪个目录。当你新插入一块磁盘想确认系统有没有识别到第一件事就是lsblk。注意清理磁盘时不要直接rm正在被进程占用的日志文件比如rm /var/log/messages之后磁盘空间可能不会立刻释放因为进程还握着这个文件的句柄。正确做法是 /var/log/messages清空文件内容或者kill -HUP 进程PID让进程重新打开日志文件。这个坑我踩过当时以为删完了结果df一看一点没变。4. 高速工作流传输、压缩、包管理与 Git4.1 服务器间传输scp、rsync 怎么选两台服务器之间传文件最朴素的方式是scp语法和cp几乎一样scp /local/file.txt user192.168.1.10:/remote/path/ scp -r /local/dir user192.168.1.10:/remote/path/-r递归传目录。scp走 SSH 协议所以确保两边 SSH 是通的。但scp有个缺点全量传输文件大了就很慢而且传了一半断了没有断点续传。如果你要同步大量文件、或者做定时备份用rsync更合适。rsync支持增量同步只传差异部分还支持断点续传和压缩。我的常用写法rsync -avz --progress /local/dir/ user192.168.1.10:/remote/dir/-a归档模式保留权限和时间戳-v显示过程-z压缩传输。注意源目录末尾的/表示传输目录里的内容而不是把目录本身也塞进去。这个细节很多人不注意传完之后发现目标路径多了一层嵌套。4.2 压缩归档tar 命令的几个关键参数打包压缩和解压是运维日常。tar命令的参数说实话挺多但常用的就这几个组合tar -czvf backup.tar.gz /data/app/ # 打包压缩 tar -xzvf backup.tar.gz # 解压到当前目录 tar -tzvf backup.tar.gz # 只查看压缩包里有什么参数拆解c创建x解压t查看z使用 gzip 压缩v显示过程f指定文件名f后面一定要跟文件名而且习惯放在最后。解压到指定目录加-Ctar -xzvf backup.tar.gz -C /opt/app/如果包是.zip格式用unzip backup.zip -d /opt/app/。压缩时想排除某目录加--excludetar -czvf backup.tar.gz --exclude/data/app/logs /data/app/4.3 软件包管理apt、yum、dnf 对照表“装软件”这件事不同发行版命令不一样我给一张对照表方便你碰到什么系统都能上手操作Ubuntu/DebianCentOS/RHEL 7CentOS/RHEL 8更新软件源apt updateyum makecachednf makecache安装软件apt install nginxyum install nginxdnf install nginx卸载软件apt remove nginxyum remove nginxdnf remove nginx搜索软件apt search nginxyum search nginxdnf search nginx查看已装dpkg -lrpm -qarpm -qa我个人的经验是先确认系统版本再选包管理命令。跑cat /etc/os-release一眼就知道。很多新手在 Ubuntu 上敲yum装不上东西就是因为选错命令了。另外不管用哪个命令装软件都建议加-y参数跳过交互确认比如apt install -y nginx不然安装到一半卡在 “Do you want to continue?” 上。4.4 Git 日常操作速查从提交到回滚Git 是开发必用也是我见过“命令没记住导致手忙脚乱”最多的地方。最基础又必须记牢的几个git status # 查看工作区状态 git add . # 把所有改动加入暂存区 git commit -m 提交说明 # 提交到本地仓库 git pull --rebase # 拉取远端代码并合并rebase 让历史更干净 git push origin main # 推送到远端最想强调的一个提交信息别偷懒。git commit -m fix这种信息三天后你自己都看不懂当时改了啥同事骂你你都不知道怎么回。至少写清楚改了什么模块、修了什么 bug比如fix: 修复用户登录时验证码过期导致500。回滚场景也经常遇到。如果刚提交了一个错误的 commit还没推到远端用git reset --soft HEAD~1撤销提交但保留改动如果想把改动也全部丢掉用git reset --hard HEAD~1。已经推到远端了就麻烦点git revert生成一个新提交来抵消错误提交避免强制推送影响到别人。5. 进阶必看Docker、GDB 与面试高频题5.1 Docker 容器管理常用命令现在问 Linux 命令面试官很可能顺手接一个“容器怎么查日志”。Docker 命令和普通进程命令是两套体系但逻辑上能一一对应。我列几个最常用的docker ps # 查看正在运行的容器-a 看全部 docker logs -f 容器名 # 跟踪容器日志等于 tail -f docker exec -it 容器名 bash # 进入容器内部 docker restart 容器名 # 重启容器 docker stop 容器名 # 停止容器 docker rm 容器名 # 删除容器排查容器问题我有个经验先看docker ps再看docker logs。如果容器在反复重启RESTART列的数字一直在涨十有八九是启动命令有问题或者依赖的服务没起来。这时候进容器内部一般也来不及优先看日志报错最直接。5.2 GDB 调试核心命令gdb是 C/C 程序调试的重型工具速查表里只写几个核心命令够你入门和应急gdb ./program # 加载可执行程序 (gdb) break main # 在 main 函数打断点 (gdb) run # 开始运行 (gdb) bt # 程序崩溃时查看调用栈 (gdb) info locals # 查看当前局部变量 (gdb) print 变量名 # 打印变量值 (gdb) continue # 继续运行到下一个断点 (gdb) quit # 退出最常用的是bt程序一崩bt一下崩溃调用栈就出来了可以直接定位到是哪个函数、哪一行出的问题。这个命令的价值怎么强调都不为过。5.3 面试高频 Linux 命令题参考结合这些年面试和被面试的经验Linux 命令相关的面试题集中在这几个方向如何查看系统负载top、uptime。要能解释 load average 的含义。如何查找占用端口 8080 的进程ss -lntp | grep 8080或者lsof -i:8080。如何实时查看日志文件tail -f或者tail -f | grep 关键字。这题很常见而且面试官常追问“如果日志文件被轮转了怎么办”答案是用tail -F大写 F它会跟踪文件重新创建。如何查看系统内存free -h。如何批量杀掉匹配某个关键字的进程ps aux | grep java | grep -v grep | awk {print $2} | xargs kill -9。这是一个组合拳面试官很爱考。如何将命令输出保存到文件并同时显示tee比如df -h | tee disk.txt。注意kill -9是要慎用的。它强行终止进程不给进程任何清理资源的机会可能导致数据丢失、文件损坏。面试问“为什么不用 kill -9”时标准回答是先kill默认 SIGTERM让进程优雅退出不行再升级到kill -9。6. 常见问题与排查技巧实录6.1 命令找不到、权限不够怎么办“command not found”是新手最常碰到的报错原因通常有几种命令没安装、不在 PATH 路径里、或者你想执行的文件不在当前目录。排查方式which 命令名 # 查看命令路径 echo $PATH # 查看 PATH 路径有哪些 ls /usr/bin/ | grep 命令名 # 看看包里有没有这个命令比如你用nslookup报 not found在 CentOS 上可能是没装bind-utils装一下就行。还有一种情况是文件明明存在直接./script.sh报“Permission denied”这是没有执行权限chmod x script.sh解决。6.2 管道与转义新手最容易踩的坑管道是 Linux 命令组合的精髓但有几个细节容易踩坑。第一grep过滤出来的进程会匹配到grep自己所以ps aux | grep nginx结果里总有一行grep --colorauto nginx这是它自己。排除办法是grep -v grep更优雅的写法是pgrep nginx。第二$符号在双引号和单引号里的行为不一样。grep error$里$有正则的意思表示行尾但在echo $HOME里$HOME是变量。如果你想把$符号当普通字符传给 grep一定要用单引号包起来grep $ file。6.3 现场排查流程一个真实故障案例去年有次生产环境的订单服务突然告警接口超时率飙到 30%。我接到通知后的排查路径是这样的top看负载发现 load average 到了 8机器是 4 核CPU 100%。确认是负载问题不是网络问题。按P排序看到java进程占了 300% 多的 CPU。多核情况下一个进程可以占多个核的 CPU这个记一下不要看到超过 100% 就觉得是 bug。ps aux | grep java拿到完整的启动参数确认是订单服务的进程。jstack PID打印 Java 线程栈发现大量线程卡在同一个方法的getConnection上初步判断是数据库连接池打满了。ss -lnt | grep 3306看数据库端口连接数确实暴涨。反馈给 DBA 排查数据库慢查询最后定位到一条新上线的 SQL 没走索引全表扫描把连接池拖垮了。整个过程大概 15 分钟核心就是先用top找到嫌疑进程再用ps确认身份最后用对应语言的排查工具Java 用jstack其他语言也有类似工具定位到具体代码层面。Linux 命令在这里扮演的是帮你在系统层面快速缩小范围的角色。排查类的技能练得多了就有手感。我自己整理了大概半年时间把上面这些命令用到“不用过脑子就能敲出来”的程度之后再遇到故障压力就会小很多。你可以在自己的机器上多模拟几遍故障场景比如故意kill一个进程、把磁盘写满、把一个端口占掉然后用这套命令体系去诊断。练过一次比看十遍速查表都管用。最后再分享一个小习惯我平时会把速查表做成一个cheatsheet.md存在本地每次遇到新命令或者踩了新坑就顺手往里面加一行。这个文件到现在已经积累了上千行但它仍然只是我的“提词器”——真正干活时靠的是手感和思路表只是兜底的。你也试着建一个属于自己的速查表吧从整理今天看到的这几条开始慢慢它会变成你的私人排障手册。