经常有人问我你到底是怎么记住那么多Linux命令的说实话我不是记性好而是早就放弃了“背命令”改用一套自己的检索逻辑。Linux命令太多常用命令其实就三四十个剩下的靠“看到不认识就查”的习惯就够了。这份速查指南就是我平时在服务器上排查问题、写脚本、跟开发对接口时反复用到的东西按使用场景整理出来给刚入门的朋友和一些被繁杂参数劝退的同学做参考。我先说清楚这份指南的价值。它不像man手册那样把所有参数铺在一起而是告诉你“某个场景应该用什么命令、为什么要用、关键参数怎么调”。适合三类人刚接触Linux的运维新人、经常在Windows和Linux之间来回切的开发以及被面试题搞得头大、想系统捋一遍命令脉络的求职者。阅读时不必从头到尾啃把目录记在心里遇到问题回来查对应章节就行。1. 先聊清楚这份速查到底帮你解决什么问题1.1 为什么会有“记不住命令”的焦虑无数人收藏过“Linux命令大全”但真到服务器上却还是会卡壳。原因很简单命令大全只有“命令参数”没有“场景命令”。我记得第一次看别人排查磁盘占用一条df -h加一条du -sh *就锁定了问题而我背过这两个命令却不知道它们之间有先后关系。所以这份指南不以命令字母排序而以“我要干什么”来组织。想通这一点你就不再需要死记硬背。1.2 先解剖一个常规命令的共性规律Linux命令看着千奇百怪实际有规律。一个命令通常由“主命令 选项 参数”构成例如ls -lh /var/log里ls是主命令-lh是选项-l表示长格式-h表示人类可读/var/log是操作对象。多数命令支持--help选项快速查看用法少数不支持--help可以用man 命令名翻全量文档。在动手查用法之前先花两分钟确认你有没有这个命令避免“command not found”直接劝退。可以用type或whichtype telnet which nctype是shell内置的能区分别名、函数和外部命令which只查PATH路径里的可执行文件。排查环境问题时这两个命令能帮你确认是不是装了别人没装的东西。1.3 管道思维是串起所有命令的胶水速查手册里隐藏的“灵魂武器”其实就是管道符|它把左边命令的输出交给右边命令处理。比如ps aux | grep java就是把进程列表里带“java”字样的行筛出来。别把每个命令当孤岛它们组合起来才是真正的“命令链”。后面每个章节我都会带上管道的组合用法因为实际排障几乎全是在玩组合。2. 文件与目录出镜率最高的命令战场2.1 文件增删改查的基本盘日常服务器操作里文件操作占了一半。先把最常用的一组列出来需求命令常用补充查看当前目录pwd用pwd -P可以看物理路径避免符号链接误导列表ls -lht-t按时间排序-h显示大小非常实用切换目录cd /data/appcd -回退上一次目录高频创建目录mkdir -p a/b/c-p递归创建没有它会报错复制cp -av src dest-a保留属性-v输出过程移动/改名mv src dest同目录移动就是改名删除文件rm -f file-f强制少用rm -rf见下方提示查看文件cat、less、tail大文件用less实时日志用tail -F特别强调一下rm -rf我见过很多事故都源于它尤其是rm -rf /path /这种中间多打一个空格的情况。首选建议是先把文件移动到临时目录观察一阵再删除也就是“先mv后rm”。很多公司都会在服务器上配置rm的回收站机制天然规避误删这个思路值得复制到个人工作机上。tail是日志排查神器最常用的两个参数是tail -n 100看最后100行以及tail -F实时跟踪文件文件被重建比如日志切割后依然能续读。相比之下普通tail -f在文件被rename后就会断掉这也是运维老手和新手处理日志时的常见差异。2.2 权限与属主别每次都用777服务器上常碰到的“Permission denied”九成和权限有关。查看用ls -l修改用chmod改属主用chown。一个常见误区是所有权限问题都用chmod 777解决实际上多数场景只需要给特定用户加权限或者改属主。一个常见的正确思路是先看当前用户是谁id再看文件属主ls -l第三列接着确认所需权限。比如要给用户appuser一个日志目录的写权限通常做法是chown appuser:appuser /data/logs chmod 755 /data/logs755的含义是属主可读写执行属组和其他人可读执行。按序调整三步就能解决大部分权限问题还会避免把文件权限搞成一个安全隐患。2.3 找文件的三条路which、find、locate找可执行文件用which找任意文件用find快速索引用locate如果装了mlocate的话。find是运维必会但参数多我常用的几组find /data -name *.log -mtime -3 find / -type f -size 500M find /data -type f -exec ls -l {} \;第一句表示在/data下找三天内变更过的log文件第二句找大于500MB的大文件第三句对搜到的每个文件执行ls -l{}是占位符结尾的\;是必须的容易漏。find很强大但全盘扫描代价高生产环境建议把扫描范围缩小到具体目录。服务器磁盘满了以后常会先df -h看哪个分区满了再用du -sh *看当前目录下各子目录和文件的大小。du最大的坑是默认不显示明细且递归较慢所以加-s只汇总加-h人类可读。定位大文件的完整链路我也会在磁盘章节再提一遍。2.4 磁盘、挂载与NAS存储排查“linux挂载nas存储”是高频搜索词实际就是网络文件系统的挂载问题。先看本机有没有挂上用df -h和mount。手工挂载NFS的典型步骤mkdir -p /mnt/nasdata mount -t nfs 192.168.10.20:/volume1/nas /mnt/nasdata挂载不上的时候先确认网络通不通ping再查NFS服务端的导出列表showmount -e 192.168.10.20本地可以用dmesg | tail看内核报错。开机自动挂载要写进/etc/fstab但建议先手工挂载验证成功再写进fstab否则重启后可能因为挂载失败导致系统卡在启动阶段。卸载倒是简单但要记得“先退出目录再umount”不然会报“target is busy”。如果确实卸载不了可以等一会儿或者用lsof D /mnt/nasdata看谁还占用着目录。3. 网络与连通性排查命令实录3.1 ping通了不代表端口通telnet、nc的实战用法很多人排查网络时报错“ping得通但应用连不上”这就是把“网络连通”和“端口连通”混为一谈了。ping测的是ICMP协议端口是否可连要靠TCP层去验证。最传统的端口连通测试是telnettelnet 192.168.1.100 8080如果端口开放会出现“Connected to 192.168.1.100”之类的提示如果连接被拒绝或超时就说明端口不通。注意telnet是明文传输在生产环境里尽量别用它传敏感数据但临时排查端口时确实很方便很多老系统没有装nctelnet客户端反而是现成的。比telnet更好用的是ncnetcatnc -vz 192.168.1.100 8080-v输出详细信息-z只扫描不发送数据。nc还能直接测试端口后面的协议比如发一个HTTP请求printf GET / HTTP/1.0\r\n\r\n | nc -v 192.168.1.100 80这比浏览器还好使能直观看到服务返回的响应头。我实际排错时最喜欢这样一条组合命令同时验证多个端口for p in 80 443 8080; do timeout 2 nc -vz 192.168.1.100 $p; done加上timeout 2防止某个端口长时间 hang 住这是日常操作里很容易踩的坑。3.2 监听与连接状态查询ss和netstat端口不通经常是服务并没有监听或者监听在错误接口上。查监听状态现在的Linux发行版我都建议用ssss -lntp-l只显示监听中的连接-n不做域名解析速度快得多-t只看TCP-p显示进程PID。输出里0.0.0.0:8080代表监听在所有接口上127.0.0.1:8080代表只监听本机回环外网自然访问不到。老系统上可能只有netstat参数类似netstat -lntpss输出更快且信息更全建议直接养成使用ss的习惯。lsof -i:8080也是查端口占用的经典方式比ss更直观地显示哪个进程占用了端口适合在系统里装了lsof的环境。3.3 HTTP、域名与DNS问题排查curl、getent、dig开发环境里最常见的“连不上”其实是域名解析或HTTP访问异常。curl是我用的最多的网络排错命令没有之一。几个高频用法curl -I https://example.com curl -v https://example.com curl -X POST -H Content-Type: application/json -d {k:v} https://example.com/api-I只拿响应头-v会打印详细请求和响应过程包括DNS解析、TLS握手、响应行、响应头。排查线上接口500错误时curl可以快速模拟请求观察返回状态码和耗时。域名解析问题用getent hosts或diggetent hosts api.example.com dig api.example.com shortgetent是系统层解析能反映/etc/hosts和DNS配置的真实结果dig更适合深挖DNS记录类型比如dig example.com MX查邮件记录。如果解析结果不是预期检查/etc/resolv.conf里的nameserver配置这是老生常谈但很多新手会把系统和应用层的DNS混为一谈。3.4 git命令开发者最常用的十几个就够虽然标题是Linux但服务端和命令行里绕不开git。“git命令”相关的搜索量常年靠前开发者常用命令其实就十几个git clone url git pull --rebase git add -A git commit -m modify xxx git push origin main git log --oneline -10 git status git diff git stash git branch -a git checkout -b feature/xxx git merge --no-ff feature/xxx我最想提醒的是git pull --rebase。团队协作时普通git pull会产生不必要的Merge commit历史变得很乱用--rebase能把本地提交变基到远端最新提交之上让日志保持线性清晰。虽然偶尔有冲突需要解决但长远来看更好维护。git stash也是救命命令。临时要切换分支但又不想提交当前改动直接git stash保存、切走干完回来git stash pop。我见太多人因为不会stash硬把半成品提交上去又后悔。4. 文本处理与编辑器命令行里的三驾马车4.1 grep过滤的三种姿势排查日志最常见的就是grep。基础用法是grep keyword file但实际工作中会用得更精细grep -n ERROR app.log grep -iv debug app.log grep -E ERROR|FATAL app.log grep -A 5 -B 5 OutOfMemory app.log-n显示行号-i忽略大小写-v反向过滤-E启用正则。排错时我最常用-A 5 -B 5把匹配行的上下文一起打出来否则光看一行错误看不出业务上下文。grep还有一种递归用法grep -r 关键字 /etc/nginx/直接扫目录里所有文件。日志量大的时候grep全量扫文件很慢我会先用tail -n 5000把最近日志截出来再grep速度会快很多。4.2 sed替换、删除、打印一次说清sed是流编辑器常用于批量替换。最经典的替换场景sed -i s/oldstring/newstring/g file.conf-i直接修改文件。注意这里有两个坑一是-i在Linux和macOS上写法不同macOS需要-i 二是替换前最好备份比如cp file.conf file.conf.bak。我有时会用sed -i.bak s/old/new/g file一步完成备份。sed还常用于删除空行和注释行sed -i /^$/d file.conf sed -i /^#/d file.conf/^$/d删除空行/^#/d删除注视行。这在解析配置时非常实用。打印某个范围的配置片段sed -n 20,40p file.conf-n抑制默认输出20,40p打印20到40行。排查配置定位范围时很方便。4.3 awk列处理与统计的穷人版Excelawk处理“按列拆分”的文本特别有用比如从ps aux或访问日志中提取字段。基础格式是awk {print $1, $2}表示打印第一列和第二列。实际场景从访问日志里统计IP访问次数awk {print $1} access.log | sort | uniq -c | sort -nr | head -20$1取IP列sort排序uniq -c统计次数sort -nr按数字倒序最后head -20取前20名。这条组合命令是日志分析刚需值得默写。awk还可以做简单的求和和条件过滤awk $4 1024 {print $1, $4} file.txt处理占比、算平均值也都在awk能力范围内。它语法不算简单但没必要一次学完先把常见的列提取和统计链路上手剩下的遇到再看。4.4 vim速查从打开文件到批量修改谈起“vim命令”很多人第一反应是“进去之后怎么退出”。我给出最小可用的vim命令集操作命令/按键打开文件vim file.txt进入编辑模式i光标前插入回到普通模式Esc保存退出ZZ等价于:wq不保存退出:q!搜索/关键字然后n下一个跳转到某行:100显示行号:set nu撤销u删除整行dd复制整行yy粘贴用p替换当前单词cw输入新词批量替换:%s/old/new/g日常运维用vim真不需要学多复杂核心就是方向键移动、i进编辑、Esc回普通、ZZ保存。词句批量替换请参照上一节sed两者不分家。vim和sed共用一套正则逻辑会一个另一个基本能猜出七成。我见过一个特别有用的习惯进入vim后先:set nu打开行号再去tail日志看报错行号回来能精确定位。整套流程行云流水。5. 系统管理与进程排查5.1 systemd服务管理和自启的常见操作现代Linux发行版基本都用systemd管理服务。核心命令就几条systemctl status nginx systemctl start nginx systemctl enable nginx systemctl daemon-reload journalctl -u nginx --since 1 hour agoenable是设置开机自启daemon-reload是修改service文件后让配置生效。我用journalctl -u看服务日志的频率非常高它比翻文件日志更省事尤其在看systemd托管服务的启动报错时。典型的服务无法启动排查链路是先systemctl status看状态和最近的日志再journalctl -xe看错误细节最后检查配置文件语法如nginx -t。盲目重启服务是最无效的排错方式因为很多错误根本不会因为重启而消失。5.2 查看进程与资源占用查进程经典组合是ps aux | grep -v grep | grep javaps aux是全量进程grep -v grep滤掉grep自身这条无关记录再筛关键词。这种写法到今天依然实用。更现代的做法是用pgrep -f java直接按进程名匹配再用pidof java查PID。资源占用排错要用top或htop。进入top后按P按CPU排序按M按内存排序按q退出。要看某个PID的资源可以用top -p PID。如果要看进程的线程、打开文件数等更细的信息可以试试pidstat -p PID 1每秒刷新一次。“linux 修改进程名称”是个冷门需求。正常情况下进程名来自启动它的可执行文件名比如java -jar app.jar的进程名叫java这会导致同时跑多个Java应用时难以区分。你可以在进程启动脚本里用exec -a自定义名称 java ...或者用systemd的ExecStart/usr/bin/java ...配合Specifier相关字段更可靠的是直接给进程设置/proc/PID/comm。但这不是常规需求实际生产环境更推荐通过pgrep -f匹配完整命令行来区分相同进程名。5.3 日志查看与快速定位日志定位是日常刚需。我一般按时间线排查tail -F /var/log/app.log less /var/log/app.log grep -n 2025-06-01 12: /var/log/app.log journalctl -u myapp --since 2025-06-01 00:00 --until 2025-06-01 06:00less打开大文件后可以按/搜索、按G跳转到末尾、按g回到开头。日志排查的真正难点在于“有海量日志但不知道搜什么”我的经验是先看错误级别最高的关键词如ERROR、FATAL、Exception再往前翻上下文。如果日志有traceId直接按traceId全链路串联能少走很多弯路。5.4 systemd之外的几个系统命令看一下系统整体状态常用uptime free -h df -h vmstat 1 5 iostat -x 1 3uptime看负载free -h看内存df -h看磁盘vmstat看系统整体运行状况iostat看磁盘IO。排查性能问题我建议按“CPU、内存、磁盘、网络”四块挨个排查别一上来就top然后瞎猜。某些系统镜像或安装类问题比如“linux镜像安装”“虚拟机安装linux蓝屏”通常会涉及启动参数和内核模块这里不展开。只说一句大多数虚拟机蓝屏是内核或者磁盘控制器驱动不匹配导致的优先检查虚拟机的固件类型和磁盘总线类型是否和发行版兼容。6. 脚本化执行与历史命令复盘6.1 一个健壮shell脚本的最小骨架“linux脚本”这个搜索词范围太宽但日常写脚本确实有固定套路。我分享一个最小健壮脚本的结构#!/usr/bin/env bash set -euo pipefail LOG_FILE/var/log/myjob.log if [ -f $LOG_FILE ]; then mkdir -p $(dirname $LOG_FILE) touch $LOG_FILE fi echo start at $(date)set -euo pipefail是精华。-e遇到错误就退出-u变量未定义就报错-o pipefail管道中任一命令失败则整体失败。没有这三行脚本往往在出错边缘“带伤运行”最终产生半成品数据。很多生产事故的根源不是命令不会写而是脚本没有失败即停止的意识。脚本里还经常要判断命令是否执行成功用退出码判断if ping -c 1 192.168.1.1 /dev/null 21; then echo reachable else echo unreachable fi/dev/null 21把标准输出和错误输出都丢弃只留下退出状态。这类写法在脚本里非常常见读别人脚本时看不懂多半就差这一句。6.2 history、cd回退、alias这些日常小习惯命令入手以后怎么提高效率我的建议是打理好.bashrc。第一件事是增大history记录量并在每条命令前记录时间戳export HISTSIZE10000 export HISTTIMEFORMAT%F %T 排查问题时history | grep firewall能帮你定位几天前到底执行过什么命令比翻聊天记录可靠得多。第二件事是配alias。常用建议alias llls -alF alias gcbgit checkout -b alias grepgrep --colorauto alias rmrm -irm -i这个alias能拦住不少误删。虽然高级用户嫌它啰嗦但作为安全默认值我觉得值得在所有个人账号上保留。cd -回退之前目录相当于Windows/Linux下快速回到上次所在路径。如果你经常在两个目录之间切换cd -比重新输入整条路径高效得多。还有一个习惯用pushd和popd管理多个目录栈但日常够用程度因人而异。7. 面试常问与故障排查方法论7.1 面试题背后的原理“linux面试题”相关搜索常年热门。面试题往往不只是背答案而是看你对系统的理解。我挑几类常考的说明一下硬链接和软链接的区别硬链接是同一个inode的多个名字删一个不影响另一个软链接是一个独立文件指向目标名目标删除后链接失效。面试官常会追问“对软链接执行rm会怎样”答案是你删掉的只是链接本身目标文件还在。文件描述符和重定向1是标准输出2是错误输出21是把错误合并到标准输出。这类题考的是你是否真在命令行处理过日志输出而不只是背语法。僵尸进程和孤儿进程子进程结束但父进程没有调用wait回收就成了僵尸进程父进程先死子进程被init接管就成了孤儿进程。排查时看到zombie状态重点去看父进程为什么没处理信号。磁盘inode耗尽df -h显示还有空间但创建文件报no space left十有八九是inode耗尽用df -i查看通常小文件太多导致的。面试准备的关键是把你真实执行过的命令跟背后的原理连起来。比如你用过find -mtime就能理解文件时间戳有mtime、ctime、atime三种很多题都是从这个小点发散出来的。7.2 现场排错的标准流程比起背命令我更想强调排错顺序。遇到“服务起不来”这种问题我自己的标准排查顺序是先看服务状态和日志systemctl status、journalctl -u找到第一处报错。确认网络层是否通ping、telnet/nc测端口区分IP层和应用层问题。确认资源是否够df -h、free -h、top很多诡异问题都是磁盘满或内存耗尽。确认进程是否存在、监听是否正确ps aux、ss -lntp。最后才看应用配置检查配置文件格式和权限。这个顺序其实是从“系统层 → 网络层 → 进程层 → 应用层”逐层收敛。很多人一上来就改配置结果发现根本不是配置问题。排错如剥洋葱一层一层来别跳步。7.3 处理安全类命令的小心说明热词里出现sqlmap、arpspoof这类工具我在这里明确说一下这些都属于安全测试工具使用场景必须有明确的授权边界。在生产环境或他人设备上执行这类命令轻则给业务带来风险重则触犯法律。日常运维排错基本用不到它们我不展开写用法。如果确实有授权的安全测试需求请走公司流程并在隔离环境中进行切勿在未授权目标上实践。8. 避坑清单与个人心得8.1 我踩过的几个坑第一个坑是crontab里的环境变量。脚本在终端手动执行正常放到crontab里却报找不到命令原因是cron任务默认不会加载用户的.bashrc和.bash_profilePATH非常精简。解决办法是在脚本开头显式声明环境比如source /etc/profile export PATH/usr/local/bin:$PATH第二个坑是du和df显示的磁盘空间不一致。df统计的是文件系统块的使用情况du统计的是文件实际大小当有进程持续占用已删除文件时df会显示空间被占满而du找不到大文件。排查方法是lsof | grep deleted把已经删除但仍被进程打开的文件找出来确认后重启或重载对应进程即可释放空间。第三个坑是Windows下编辑过的脚本在Linux上报“bad interpreter”。这是因为文件被保存成了带\r\n换行符的格式解决办法是sed -i s/\r$// script.sh这个坑在跨平台协作时非常常见用file script.sh能快速看到文件格式信息。8.2 我保留的几个命令习惯每个熟练的从业者都有自己的“肌肉记忆”。我个人最依赖的三条组合命令是ss -lntp看端口占用、journalctl -u 服务名 --since 1 hour ago看服务日志、awk {print $1} access.log | sort | uniq -c | sort -nr做基础统计。这三个场景覆盖了我日常七八成的排障需求。还有一个小习惯凡是改动配置文件前先复制一份带日期的备份。比如cp nginx.conf nginx.conf.bak.20250601。看起来多了一步但回滚时能节约半小时以上这个习惯救过我很多次。最后多说一句Linux命令速查这件事不要囤成文档就完事。最快的速查其实是你自己的终端历史多敲多用把常用命令变成条件反射比任何手册都管用。这份指南的各个章节按需查阅关键是让每一条都落到你手头真实的服务器和项目里去。遇到看不懂的参数man或--help永远是离你最近的老师。