1. 先搞清楚这件事为什么人人都说“常用Linux命令”却依然一堆人用不明白“常用的Linux命令”这个title听起来像是个三天就能抄完的入门清单但真正靠命令行吃饭的人都知道命令只是一个壳藏在里面的是你对系统的理解程度。我见过不少同事能流利背出几十条命令可一到线上排查就直接抓瞎不是因为命令记得少而是他们不知道什么场景该用什么命令、参数怎么组合、输出该怎么解读。这个内容能解决的就是这件事把日常使用率最高的一批Linux命令按照“我是谁、我在哪、我要干什么”的思维拆开让你在几秒钟之内就能选出合适的命令并且看懂输出里的关键信息。适合谁来读刚入行的运维、后端开发、数据相关岗位的朋友都适合。就算你只是自己有一台云服务器也会发现把这些命令吃透了比装一堆图形面板管用得多。我不打算列那种每个命令带一行解释的cheat sheet那东西网上一搜一大把真正缺的是“为什么这样用”和“踩坑之后怎么办”。我先说说自己的一点体会。以前被公司拉去处理一次磁盘被打满的问题现场所有人都盯着监控面板看只有一个人开终端用了一连串命令从df定位到目录用du揪出大文件再用find把过期日志筛出来清理整个流程不到十分钟。事后他跟我说Linux命令的本质不是“记住指令”而是“建立排查链路”。从那以后我就把常用的命令整理成了场景化清单这篇文章就是这份清单加上后来不断补充的实战经验的完整版。1.1 为什么我建议按场景来记命令而不是按命令列表去背很多入门教程喜欢按照“文件命令、网络命令、进程命令”这种维度来罗列比如ls一条、cd一条、ping一条。这种整理方式不能算错但它最大的问题是没有“使用场景感”。你背下来的是一堆孤立的命令遇到真实问题的时候很难联想起来该调用哪一条。我的习惯是反过来每次先描述一个场景比如“服务启动不了”“日志文件增长太快”“网站突然很慢”然后自然带出这个场景下会用到哪几条命令、它们怎么配合。举个例子。排查网站变慢这个问题如果按命令去背你顶多想到top、ps、free这串名字如果按场景去推你会想到先看负载top一眼能看到load average然后再看CPU和内存占用如果负载很高但CPU不高就要怀疑是不是I/O瓶颈这时候iostat和iotop就出场了。这种链条式记忆不会轻易忘而且你积累的每个场景排查思路本身就是一条条命令的组合用法。1.2 环境准备不需要一台中心服务器一个终端就够了后面所有命令我都建议你边看边敲别光读。准备方式很简单如果你本机就是Linux或者装了虚拟机和子系统直接开终端手上只有Windows也没关系用自带的终端配合云服务器也能跟上。为了照顾新手我下面给出的命令大多都会带上参数含义和输出解读但我不打算解释每一个基础概念遇到不清楚的可以临时用man命令去查帮助这也是一个常用的Linux命令习惯。我强调一遍学命令最忌讳眼高手低看一遍以为会了真正上手才暴露问题。我见过太多人把命令复制进终端报错了也不知道怎么改原因就是他没理解参数的含义只是机械粘贴。所以下面每个关键步骤我都会刻意解释参数为什么这样写替换成别的值会有什么效果。2. 文件与目录操作这些命令是每天的肌肉记忆但有几个细节常被忽略2.1 ls、cd、pwd用多了你自然会懂但我要补充三个容易被忽略的点ls大概是所有人接触的第一条Linux命令但我发现很多人在实际工作中依然只会用ls和ls -l。这样够用吗能用但效率差很多。先说我最常用的几个变体ls -laha是显示隐藏文件h是用人类可读的方式显示大小这个组合几乎每天都要用。再有ls -lt按照修改时间倒序排列找最近改动的文件特别方便排查配置文件改错的时候一敲就能定位。还有ls -lR这个慎用目录层级多的时候输出爆炸尽量用find替代。cd命令看起来更简单但有两条实用技巧值得记住。一条是cd -它表示回到上一次所在的目录在两三个目录之间来回切换的时候非常顺手免去了反复打长路径的麻烦。另一条是cd ~回到当前用户的家目录这在配合su切换用户之后尤其好用因为不同用户的家目录不一样直接打绝对路径容易出错用cd ~永远安全。pwd就是打印当前目录路径防止自己在多层目录里迷路这在写脚本拼接相对路径时更是救命的工具。关于路径还有一个新手容易迷惑的地方相对路径和绝对路径。绝对路径是从根/开始写相对路径是相对于当前目录写。我的建议是在脚本和配置文件中尽量写绝对路径在交互式终端里为了省事可以用相对路径但要注意当前目录别搞混。某次我看到同事的一条清理脚本里写了rm -rf ./logs结果在cron里因为当前工作目录变成根目录直接把根目录下的同名文件夹给删了这就是相对路径在自动化任务里造成的悲剧。2.2 cp、mv、rm安全习惯永远比事后补救重要文件复制和移动是每天都在做的事但我要认真说一句rm命令是真的会搞出大事的。我自己赔过一台服务器的数据目录虽然不是生产核心但那次经历让我养成了一个习惯凡是批量删除之前先ls或者find列出要删的东西确认无误再用rm。更稳妥的做法是删除之前先mv到一个临时目录比如/tmp/tobedeleted观察一天再清理这样恢复成本极低。cp的常用参数是-r和-a。复制目录必须加-r但-a的含义更丰富它等于-dR --preserveall也就是保留文件属性、时间戳、软链接并在复制目录时递归处理。需要备份服务配置或迁移环境时用cp -a比cp -r要稳得多因为很多服务靠文件权限和时间戳判断状态丢了这些信息会留下一堆后患。mv在同分区内只是改名速度快跨分区时则是先复制再删除耗时会明显增加这个区别在移动大文件时体感很明显。这里要特别提一下通配符配合rm的危险。命令rm -rf *在历史上已经酿过太多事故尤其当变量为空时扩展出来的rm -rf /后果不是谁能轻易承担的。一个防御习惯是在rm命令前先加echo测试如果回显出来的是你真正想删的文件再把echo去掉执行。虽然看着多了一步但这个习惯能拦截掉大部分手滑操作。3. 文本处理命令Linux命令能拉开差距的地方基本都在这块3.1 grep从“找到一行”到“找到问题”差的只是参数选择grep是文本处理里的门面但很多人只停留在grep xxx file的层面。实际工作中最常用的是加上下文比如grep -C 5 error app.logC表示前后各5行这样你看到的就不是孤零零一条报错而是报错前后的日志现场。如果你只想看之后的日志用-A 5只想看之前的用-B 5。排查线上问题时这条命令的实用性远超你的想象。另一个关键参数是-E表示使用扩展正则表达式。比如同时过滤多个关键词grep -E ERROR|Exception|Timeout。如果是固定字符串匹配完全可以用grep -F来加速尤其在匹配超长字符串时-F会把内容当作固定字符串而不是正则去解析执行快很多。搜索时忽略大小写用-i比如grep -i error会同时匹配Error和ERROR某些业务场景输出大小写不固定这个参数能帮你避免漏查。还有一个高频组合是grep -v表示反向匹配剔除某个关键词的行。看日志的时候有时报错行里混杂着大量已知的健康检查日志用grep -v heartbeat把噪音过滤掉剩下的内容才是真正需要关注的。配合管道grep -r也可以递归搜索目录比如grep -r api_key /etc/nginx/可以快速找出哪些配置里写入了敏感内容。值得提醒的是grep只能逐行匹配跨行匹配不是它的强项这种情况建议换pcre2grep或者配合awk、sed完成。3.2 sed与awk初看很劝退一旦上手就回不去了sed和awk被称为文本处理三剑客中的两位也常常是新手劝退的重灾区。我的建议是不要一开始就啃全量语法先记住每个工具的“日常20%”。sed的核心场景是替换和删除。比如要把配置文件里所有localhost替换成127.0.0.1一行命令就能搞定sed -i s/localhost/127.0.0.1/g config.conf。这里的-i表示直接修改文件不加-i只输出到屏幕不落盘。如果你还不确定替换结果对不对千万不要上来就加-i先跑一遍不带-i的版本确认没问题再实际修改。awk的核心场景是取列和做统计。默认按空格或Tab切分比如一个日志文件每行格式是“IP 时间 请求路径 状态码”要查看状态码为500的行可以awk $4500 {print $0} access.log。$0表示整行$1是IP$2是时间以此类推。再比如按状态码统计数量awk {count[$4]} END {for (code in count) print code, count[code]} access.log。这段虽然有点长但它就是一条命令完成了分组统计如果你不会它就得写半天的Excel公式。我在实际工作中遇到过一种场景日志里时间格式是2024-08-01 10:00:00我要统计每个小时出现的错误数量。如果只用grep得到的是无数行细节没法直接看趋势换成awk按小时字段聚合一条命令就能得出1小时粒度的错误分布。像这种“日志数据透视表”awk做起来干净利落。需要补充的是如果文本结构很规整可以优先考虑用awk如果结构混乱、提取规则复杂建议先sed清洗格式再交给awk处理两个工具配合效果更佳。3.3 cut、sort、uniq、wc日志分析里最不起眼的组合拳这组命令单看都不难但组合起来能完成不少数据清洗工作。比如一个请求日志文件先cut -d -f1提取IP列然后sort排序再用uniq -c去重并统计次数最后sort -rn按次数倒序排这一套下来就能输出访问量排名前十的IPcat access.log | cut -d -f1 | sort | uniq -c | sort -rn | head -10。我第一次把这套组合用出来的时候整个人是有点小激动的因为这种场景在日志分析里太常见了。这里的细节是uniq命令只能合并相邻的重复行所以必须先sort否则统计结果是错的。sort -n表示按数值排序而不是按字典序排序不加-n的话数字10会排在2的前面。wc -l可以统计行数我经常用它来确认日志切割、导入任务的数据量是否正常。接手一批数据后先wc -l看一下再抽样head或tail看格式是避免“后续命令全明艹在脏数据上”的捷径。4. 进程、网络与系统资源从“看得见现象”到“看得懂原因”4.1 ps、top、kill定位和干预进程的基本功服务出问题的时候第一反应是看进程还在不在这就是ps的用武之地。我常用的命令是ps -ef | grep java或者ps aux | grep nginx。-ef是用标准格式列出所有进程aux是用BSD风格列出所有进程两者都能用来找到进程的PID。不过强烈建议grep的时候把自己排除掉比如grep [j]ava这种写法它利用正则匹配的特性过滤掉grep进程自身带来的干扰行是个很实用的小技巧。看清进程状态之后top命令能帮你了解系统整体资源占用。top输出第一行的load average是重点三个数值分别对应过去1分钟、5分钟、15分钟的负载情况。如果三个数都在涨说明负载是近期起来的如果15分钟很高但1分钟降下来了说明高峰期过去了系统正在恢复。看进程占用的CPU和内存时按P按内存排序按M按内存排序这两个交互键要记牢。还有top -Hp PID可以查看某个进程内所有线程的资源占用排查Java应用CPU飙高时基本都是先靠它定位到具体线程再用线程号去查栈信息。kill命令用来结束进程kill -9是强行终止kill -15是礼貌请求终止。不要一上来就kill -9很多服务要处理退出前的工作比如写缓冲、释放锁、通知节点下线直接强杀会造成数据不一致或集群脑裂。正确的顺序是先kill -15等几秒看进程是否退出不行再kill -9。我踩过的坑是强制杀掉一个数据库从节点的进程结果主节点同步状态迟迟没有切换回来很多请求直接失败后来才发现是没等优雅退出。杀掉进程之前建议先用ps确认PID没有认错避免误杀别人的服务。4.2 网络诊断ping、ss、curl一条龙排查TCP层问题网络诊断这块ping最基础但它只能证明两台设备之间的IP层通不通不能说明端口通不通。判断端口是否能访问我习惯用ss -lntp查看本机监听的端口和对应进程再用telnet或者nc去做一次TCP连通性测试。ss是netstat的现代替代品输出更快也更清晰-l表示只显示监听状态的socket-n表示不解析服务名-t表示只显示TCP-p表示显示对应进程。这个组合基本可以替代我大部分netstat使用场景。curl是个被低估的常用命令很多人只知道它能下载文件实际上接口调试、HTTP状态检查都靠它。我在排查接口超时问题时最常用的写法是curl -v http://目标地址-v会输出详细的握手和请求头信息从DNS解析、TCP连接、TLS握手到HTTP响应哪个阶段卡住了都能看到。加上-o /dev/null -w %{http_code} %{time_total}\n可以只输出状态码和总耗时适合脚本里做健康检查。如果怀疑代理干扰还可以加--noproxy *绕过本机代理设置。线上排查时curl -I用来查看响应头是否正常比如判断缓存是否命中、服务端是nginx还是其他中间件有时候一眼就能找准方向。4.3 磁盘和内存看一眼就能判断是不是快没空间了磁盘用df -h查看输出里最怕看到使用率100%。这时候需要用du -sh /目录逐层定位或者用du -h --max-depth1查当前目录下第一级子目录的大小。很多人不看du参数说明直接在根目录跑du -sh如果文件很多执行会非常慢因为du要遍历每个目录。配合sort -h可以按人类可读的大小排序比如du -h /var/log/| sort -h | tail -20一次性找出最大的几个文件或目录。排查磁盘占用时还要注意已删除但还被进程占用的文件用lsof | grep deleted能找出来这种文件虽然你删不掉但只要重启对应进程空间就会释放。内存使用用free -h查看注意available和free的区别。free是真正还没被用的内存available是估算的可被分配的内存包括可回收的缓存。所以看起来free很小不用慌只要available还够业务使用系统就还没到危险线。要是available持续走低同时swap在持续增长说明物理内存已经不够用了。这里有个补充习惯排查内存问题别只看free最好配合top或ps aux --sort-%mem找出具体的吃内存进程才能定位责任方。5. 权限、用户与远程操作常用命令里最容易被抄错的一组权限管理是Linux命令里非常容易出错的部分新手常见的坑是把权限数字记混。chmod 755 file表示所有者rwx、组rx、其他人rx这组数字的底层逻辑是r4、w2、x1加起来就是对应的权限值。我自己记的时候习惯用“所有者权限写全组和其他人只读可执行”作为默认值大多数目录和程序文件用755是合理的。但如果文件要被人写就需要664或666具体取决于是否允许所有人修改。要变更文件所属关系时用chown user:group file比如chown -R nginx:nginx /data/www-R会递归处理目录下的所有内容。用户切换用su -和sudo。su - 用户名表示切换用户并加载其环境变量sudo则允许特定用户以其他身份执行命令。日常运维中能用sudo就不要直接su到root因为sudo的权限操作会被记录下来出了问题还能追溯是谁在哪台机器执行了什么命令这个审计价值对多人协作环境特别重要。我也见过很多团队因为人手一个root权限出了故障只能靠猜操作记录最后吵架都找不到依据。所以我的建议是别图省事给该用的权限留该留的审计。远程操作主要靠ssh。ssh userhost是最基础的登录方式但实际中使用ssh密钥登录比密码登录更安全也更方便。配置方式是把本机的公钥追加到目标机器的~/.ssh/authorized_keys文件里很多云服务器控制台也支持直接注入公钥。登录之后如果需要传文件用scp或rsync。scp适合一次性拷贝rsync则适合增量同步和目录迁移比如rsync -avz /src/ userhost:/dst/-a是归档模式保留权限和时间戳-z是传输时压缩-v是显示过程。rsync断点续传和失败重试的能力使得大批量文件迁移时比scp靠谱得多。6. 高频命令避坑手册这些都是我实际操作中踩过的坑6.1 命令没反应但系统没崩先查这几个原因第一种是通配符没匹配到任何文件某些命令直接报错比如rm *.log在没有日志文件时会提示No such file or directory。第二种是权限不足很多系统文件只有root能读或执行普通用户跑ls /root会报Permission denied这时候就要考虑加sudo。第三种是命令确实不在PATH路径里比如你自己编译安装的软件安装在/usr/local/xxx/bin下面终端却找不到命令这种情况可以先看echo $PATH确认搜索路径再确认是否需要做软链接。第四种是磁盘满了任何写入操作都会报No space left on device用df -h看一眼就明白了。我还遇到过一种比较隐蔽的情况一条命令在交互终端里执行没问题但放到cron或systemd定时任务里就失败多半是环境变量不同。cron环境非常精简很多PATH和自定义变量都没有加载解决办法是脚本开头显式export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin或者调用命令时用绝对路径。这个坑我曾经排了一晚上最后发现是因为脚本里用的命令在cron环境里找不到白白耗了时间。6.2 日志排查会遇到的标准操作流程遇到线上问题我的第一个动作永远是cd /var/log或项目日志目录然后ls -lt看最新日志文件是哪个再用tail -n 100或者tail -f追踪输出。-f表示持续跟踪适合看运行中服务的实时日志。如果日志刷屏太快可以配合grep过滤比如tail -f app.log | grep ERROR这样屏幕上只有错误信息不会淹没在正常日志里。如果需要从历史日志里找某个时间段的上下文因为日志太大不能直接grep可以先用时间范围截取比如sed -n /2024-08-01 10:00/,/2024-08-01 10:30/p app.log它会在匹配到的两个时间戳之间打印所有行这样能显著缩小范围。6.3 一个常用命令的可疑变体当心没有任何回显的操作前面提到过rm -rf的危险性我再补充一个容易出事的场景很多人习惯在命令后面加2/dev/null来屏蔽错误输出结果导致命令失败时完全不知道。比如rm -rf /data/backup 2/dev/null如果因为权限不足删除失败你没有任何提示备份目录还在原地存着直到某天占满磁盘才发现问题。我的建议是重要操作不要随意丢弃错误流保留输出可以让你在第一时间发现命令执行情况。就算一定要丢弃也应该用日志重定向记录下来比如2/var/log/cleanup.err事后可以排查。另外Linux命令有一个很值得养成的习惯先echo一遍自己的完整命令再实际执行。比如准备执行rm -rf /data/old/logs可以先改成echo rm -rf /data/old/logs确认回显的内容无误后再真正执行。这一招对批处理、在生产环境运维的人来说特别有用看起来多了一步实际上给自己留了一次后悔的机会。7. 把这些命令串起来一个完整的“30秒排查”实例说了这么多我拿一个真实的排查路径来收尾。假设你在某台服务器上部署了一个服务用户反馈接口突然很慢。你会怎么做第一步登录服务器先用top看负载如果load average飙到很离谱直接进入第二步。第二步用ps aux --sort-%cpu | head -10看哪个进程在吃CPU如果吃CPU的正好是你那个服务用top -Hp PID找到具体线程如果想看每个线程的CPU占比可以用ps -Lp PID -o pid,tid,pcpu,comm --sort-pcpu | head。第三步如果CPU不忙但系统很慢就要怀疑I/O瓶颈用iostat -x 1看看util是否接近100%。第四步网络层面可以用ss -lntp确认服务端口是否正常监听再用curl -w“耗时”去看接口响应时间对比正常时期的数据。最后翻日志用tail -f和grep ERROR定位报错。这个过程每一步都用的是前面讲的常用命令单看都不复杂串起来就是可靠高效的排查链路。我个人最大的体会是Linux命令真正难的不是背而是建立这种“看现象-猜原因-用命令验证”的闭环。刚入门时我隔三差五在网上查“Linux查看CPU命令”“Linux查找文件命令”后来发现查一次记不住是因为我没有把命令放到真实问题里。直到某次真的被磁盘占满、被日志刷屏在紧张的环境下被迫用那些命令解决问题它们才真正长在了我脑子里。最后再分享一个小技巧你可以用alias给高频命令设置一个顺手且安全的别名比如alias llls -lht这样每次想看最新修改的文件直接ll就行或者alias rmrm -i让rm默认询问确认。但要注意alias在脚本里默认不生效真正的核心操作还是要靠扎实的命令基础别把所有希望寄托在别名上。我把这些内容整理成了一份自用清单如果你也是靠终端吃饭的人建议照着这个思路沉淀出你自己的“常用命令场景表”遇到问题别急着搜先想想你在哪个场景里需要哪个环节的命令。