用了十年 Linux说实话我现在每天还在敲命令但每次看到新人一上来就死记ls -la、grep -r我都觉得挺心疼的。命令这东西背是背不完的关键是你得理解它背后的设计逻辑和你自己的使用场景。这篇东西不打算讲那种史上最全 100 个命令的清单我尽量从一个老折腾的角度聊聊 Linux 命令里最核心、最高频、也最容易出问题的那些部分顺便把我在生产环境里踩过的坑、沉淀下来的思路一起放出来。适合刚入门的同学建立自己的命令体系也适合用了一段时间但总觉得效率上不去的朋友做一次系统梳理。1. 先想清楚学习 Linux 命令到底在学什么1.1 命令不是背出来的是组合出来的很多人学命令有个误区总觉得要像背单词一样把每个命令的所有参数都背下来才算学会。我见过最离谱的是一位朋友拿一本几百页的 Linux 命令手册在那啃啃了三个月遇到实际问题还是会懵——因为他只记住了单个命令是干嘛的但没搞明白命令之间是怎么协作的。Linux 命令的核心思想其实非常朴素一个命令只做好一件事然后通过管道|、重定向、转义$(...)这些机制把多个命令串起来组合成一条完整的处理链路。比如你要查一个服务的进程是否还活着一条ps aux | grep nginx就是两个命令的组合你要统计日志里某个错误出现了多少次grep ERROR app.log | wc -l又是两个命令的组合。熟悉了这种组合方式你就不会陷入背参数的泥潭因为你发现自己真正需要掌握的其实是那么二三十个命令的用法和组合规则。这里的核心是管道哲学前一个命令的标准输出变成后一个命令的标准输入。你可以把它想象成一条流水线每个命令就是一个工位处理完了交给下一个人。这条流水线上的每个工位都很简单但组合起来能完成非常复杂的任务。掌握了这个心智模型你会突然发现 Linux 命令行不再是一个个孤立的工具而是一套完整的、可以随时组装的操作系统接口。1.2 三条主线快速定位你的知识盲区我习惯把命令分成三条主线来学习。第一条是文件与目录包括ls、cd、find、tar、cp、mv、rm这类命令解决的是东西放在哪、怎么挪、怎么打包的问题。第二条是文本处理包括grep、awk、sed、sort、uniq、cat、tail解决的是内容怎么读、怎么找、怎么改、怎么统计的问题。第三条是系统与状态包括ps、top、df、du、free、netstat、ss解决的是系统现在怎么样了、瓶颈在哪的问题。把这三条主线装进脑子里你遇到任何问题都能快速归类是找文件的问题走主线一还是处理文件内容的问题走主线二还是系统性能的问题走主线三。分类越快你的排查路径就越短。我见过很多初级运维一上来就top看 CPU结果问题是磁盘满了或是一上来就grep日志结果连日志文件在哪都不知道。这些其实都是知识盲区导致的——你不知道有哪些命令能解决当前的问题就只能用自己唯一会的那一个自然事倍功半。所以这篇文章的主体我也会按这三条主线展开每条主线挑出最核心的命令重点讲参数背后的逻辑和使用时机而不是把 man 手册抄一遍。2. 文件和目录操作最基础也最见功底2.1 ls 和 cd 的隐藏参数你真的用对了吗ls大概是所有人接触的第一个命令。但用三年和用十年对ls的理解完全不同。我刚工作时习惯ls看列表后面发现生产环境里文件名可能带各种奇怪的字符、隐藏文件、权限状态这些信息单靠裸ls是看不全的。真正高频的场景是ls -lah-l显示详细权限和属主-a显示隐藏文件-h把文件大小换算成人类可读的 K、M、G。为什么-a重要因为很多配置文件都是.开头的隐藏文件比如~/.ssh/config、~/.bashrc漏看它们你会觉得明明改了配置为什么不生效。还有一个容易忽略的参数是-t按修改时间排序。排查最近到底哪个文件被改了时ls -lt配合head可以直接列出最近修改的几个文件如果想递归看某个目录下的所有文件ls -R能帮上忙但说实话我更推荐用它来快速扫一眼目录树真正常规的查找需求还是交给find。cd本身参数不多但有几个习惯值得养成。一是cd -可以回到上一个所在目录在两个目录之间反复横跳时会给你省下很多输入。二是cd进一个很深的目录后想返回上层但不想一级一级敲cd ../..是笨办法pushd和popd才是正解——pushd /var/log/nginx压栈入目录popd弹栈回到之前的位置。很多人不知道这两个命令导致在多层目录间来回切换时只能痛苦地重复敲长路径。2.2 find 的几种玩法与匹配优先级find是文件查找的王者但也是我最常看到新人误用的命令。最典型的错误是找文件用find / -name *.log结果等了半天没响应因为-name是精确匹配文件名包括路径中的目录名而如果要从根目录开始找这个命令会遍历所有挂载点一旦命中网络磁盘、虚拟文件系统速度会非常慢。我在实际使用中通常会加上路径范围比如find /var/log -name *.log甚至再加-mtime -7只找七天内的文件。find的第二个关键点是匹配优先级。常见的参数组合是-type f只找普通文件、-type d只找目录、-mtime N修改时间超过 N 天、-size 100M大小超过 100M。这些条件可以直接用运算符连接-a表示 AND-o表示 OR!表示 NOT。举个实战场景清理一个目录下的过期备份文件我会用find /backup -type f -name *.tar.gz -mtime 30 -delete这条命令的意思非常直白找/backup下所有超过 30 天未修改的 tar.gz 文件并删除。注意-delete必须放在最后因为find的执行顺序是表达式从左到右求值如果你把-delete放在中间后面的条件可能都不会生效。还有一个我踩过坑的地方find的输出如果包含空格或特殊字符的文件名直接交给xargs处理会有问题。正确做法是在find里用-print0然后在xargs里用-0这样文件名以 null 字符分隔空格、换行、括号都能安全处理。这个坑在我第一次写批量重命名脚本时差点把一批文件搞乱幸好先在一个临时目录里测试了一遍。2.3 tar 打包解包参数顺序与压缩格式选择tar这个命令说简单确实简单但出问题的频率非常高。最常见的错误是把参数顺序写反比如tar -cvf backup.tar.gz /data你明明想压缩结果只打了包没压缩因为压缩需要-zgzip或-jbzip2。习惯上我会把压缩选项放在前面tar -czvf backup.tar.gz /data。还有人说记不住参数其实拆开看就四个字母c是 create创建、z是 gzip压缩、v是 verbose显示过程、f是 file指定文件名。解包时则是tar -xzvf backup.tar.gz这里c换成xextract。为什么f必须写在最后因为tar的老传统是f后面紧跟文件名你不把f放最后它会把后面的东西都当成文件名。这个细节吃过亏的人应该不少。另外解压到指定目录用-C比如tar -xzvf backup.tar.gz -C /tmp/restore这个参数在整理归档文件时特别实用。压缩格式的选择也有讲究。同样的数据gzip 压缩快、体积稍大bzip2 压缩慢、体积更小xz的压缩率最高但耗时也更长。日常备份我建议直接用tar -czvf生成 gzip 格式通用性最好几乎任何 Linux 发行版都支持。如果日志归档、不常解压的冷数据可以用tar -cJvfJ是 xz省空间。时间敏感、机器性能又弱的场景甚至可以用tar -cvf不压缩直接打包速度最快。归根到底压缩率和时间永远是需要权衡的没有绝对最优的方案。3. 文本处理三件套grep、awk、sed3.1 grep 的常用选项和正则要点grep是排查问题时的第一把刀它的作用是从文本里捞出你想要的行。基础用法grep keyword file谁都会但有几个选项能让效率提升一个量级。第一是-E启用扩展正则表达式新手最容易在这一步卡住因为默认的grep用的是基础正则、?、|这些符号都需要转义才能用。比如你想匹配 error 或 warning用基础正则需要写grep error\|warning而加了-E之后可以写成grep -E error|warning直观得多。所以我的习惯是只要涉及正则一律加-E。第二个高频选项是-i忽略大小写。排查日志时关键字可能是Error、ERROR、error三种写法都有没有-i会漏掉大量信息。第三个是-v反向匹配过滤掉不要的行搭配管道使用时非常常见grep -v ^#可以过滤掉配置文件中以#开头的注释行只留有效配置。第四个是-r或-R递归搜索目录这在源码目录里找函数定义、在配置目录里找某个参数时是刚需。还有-n显示行号排查日志时没有行号等于没查——你得知道错误发生在哪一行才好定位上下文。正则表达式本身是个大话题这里只讲最核心的。.匹配任意单个字符*匹配前一个字符零次或多次^锚定行首$锚定行尾[abc]匹配括号内任意一个字符。只要有这五个概念配合-E你就能处理 80% 的匹配需求了。遇到更复杂的需求再去看字符类[0-9]、[a-z]和量词{m,n}也不迟。3.2 awk 入门列处理与内置变量awk是文本处理三件套里门槛最高的一个但也是威力最大的一个。它的核心心智模型是把每一行按分隔符拆成多个列然后你可以基于列做过滤、计算、格式化输出。最常见的需求是从ps、df、ls的输出中提取某一列的数据。比如ps aux | awk {print $2}就能打印出所有进程的 PID。$0表示整行$1表示第一列$2表示第二列依此类推。awk的第二个常用维度是内置变量。NR是当前处理的行号NF是当前行的列数FS是字段分隔符默认是空白。比如你想看/etc/passwd里所有用户的登录 shell可以用awk -F: {print $1, $7} /etc/passwd-F:表示按冒号分隔因为 passwd 文件里每列是以冒号分割的。这个-F选项非常常用处理日志时配合自定义分隔符更是如虎添翼。比如一条 Nginx 访问日志各字段通常以空格分隔但有些自定义日志会用竖线|分隔你就可以写awk -F| {print $2}提取指定字段。再进阶一步awk还能做条件过滤和统计。awk $3 100 {print $1}表示当第三列大于 100 时打印第一列awk {sum $1} END {print sum}则可以对第一列求和。END是 awk 的特殊模式表示所有行处理完之后执行一次。这种语法在处理监控数据、统计接口耗时平均值时非常好用我经常用一行 awk 把某个接口的响应时间算个平均值而不用写脚本来处理。3.3 sed 的增删改查实操sed跟awk不太一样它的强项是就地编辑流的文本。核心操作就四个增a、删d、改s、查p。其中最常用的是替换语法是sed s/旧/新/。注意一个细节默认只替换每行第一个匹配到的内容如果你想替换全部要在末尾加g写成sed s/old/new/g。这种差异在批量改配置的时候特别容易出问题——你改了但没改完后面排查时一脸懵。sed的删除功能也很实用。sed /^#/d config.conf能把以#开头的注释行全部删除配合前面说的grep -v有异曲同工之妙。sed还支持按行号操作sed 3d file删除第三行sed 5,10d file删除第五到第十行。这在处理一些格式化的数据文件时非常有用。很多人把sed -i当成生命不能承受之重因为一旦用不好会直接改坏原文件而且没有后悔药。我的建议是无论如何先用不带-i的命令在终端上跑一遍确认输出是你想要的再加-i执行。这是我用 sed 多年的铁律。特别是面对生产环境的配置文件先备份一份cp file file.bak再执行替换最后确认没问题再删备份——这基本是标准流程。还有一个技巧sed -i.bak可以直接在备份原文件的同时执行修改sed -i.bak s/old/new/g file会生成一个file.bak作为原文件的备份然后修改file这个语法很值得记。3.4 管道与组合一行命令解决日志分析前面说管道是 Linux 命令的核心思想现在我们把 grer、awk、sed 组合起来演示一个真实场景。假设你手里有一个 Nginx 访问日志access.log每一行的格式类似192.168.1.5 - - [21/Jul/2025:10:15:30 0800] GET /api/user HTTP/1.1 200 532 192.168.1.8 - - [21/Jul/2025:10:16:02 0800] POST /api/login HTTP/1.1 500 1024现在你想知道返回状态码为 500 的请求一共有多少次一条命令就够了grep 500 access.log | wc -l注意这里grep匹配的是 500 前后带上空格是为了避免误匹配到请求时长 500ms 之类的字段。wc -l统计行数得到的就是次数。如果你还想看哪些接口最容易报 500可以继续组合awk和sortgrep 500 access.log | awk {print $7} | sort | uniq -c | sort -rnawk {print $7}提取出请求路径第七个字段sort排序让相同路径聚在一起uniq -c统计每个路径出现的次数sort -rn按次数降序排列。这样一条命令执行完接口的 500 排行直接出来了不用写脚本也不用查数据库。这就是组合命令的威力工具都是现成的只要你会把它们串起来。4. 进程与性能排查系统变慢时你在干什么4.1 ps、top、htop 的视角差异系统变慢的时候绝大多数人的第一反应是敲top。这个反应没问题但我建议先想清楚你看到的是实时快照还是历史趋势top显示的只是当前时刻的进程状态和资源占用如果 CPU 峰值已经过去了你打开top可能什么也看不到。top的第一个优点是简单但长期观察不够htop更直观可以按 F6 选择排序字段滚动查看所有进程还能用鼠标操作但在最小化服务器没有图形环境上往往没装。ps的优势在于查询当前进程的完整状态。最常用的组合是ps aux或ps -ef两者都输出完整进程列表差别主要在列名和格式。ps aux会更直观一些ps -ef则更接近 Unix 传统风格。我常用的方式是ps aux --sort-%cpu | head按 CPU 占用排序看前几个进程。这条命令在系统突然变慢时几乎百试百灵——它直接告诉你 CPU 是谁吃掉的都不用猜。如果是内存问题就把排序字段换成-%mem。查具体进程时pgrep比ps aux | grep更精准。pgrep -f nginx可以直接返回匹配进程的 PID而且不会把 grep 自身的进程也算进去——这是ps aux | grep nginx的经典尴尬结果里总有一条grep自己的进程让初学者困惑不已。想彻底避开这个问题也可以用pgrep -f或ps aux | grep [n]ginx的写法后者是正则的技巧让grep匹配不到自己。4.2 磁盘与内存df、du、free 的读数方法磁盘满了是运维最常见的故障之一。排查顺序应该是先用df -h看整体挂载点的使用率再用du定位具体是哪个目录占了大头。df -h里的-h跟ls -ah一样是把数字转成人类可读的单位。如果某个分区使用率到了 90% 以上基本就该考虑清理或扩容了。但注意df看的是文件系统层面的使用量有些文件被删除后进程仍然持有句柄磁盘空间并不会立即释放这种情况后面我会专门讲。du的常用法是du -sh *统计当前目录下每个子目录的大小du -sh /var/log只看指定目录的总大小。排查磁盘占用时我习惯从根目录开始逐步缩小范围du -sh /* 2/dev/null先把根下每个一级目录的大小列出来找到异常大的目录再进去继续du -sh *这样用不了几步就能定位是大文件还是某个子目录撑爆了磁盘。free -h用来查看内存使用情况。很多人看到free的输出会误判可用内存太少但实际上 Linux 的内存管理有buff/cache这一项它表示用于文件缓存的内存是可以随时释放给应用程序用的。真正需要关注的是available这一列——它才是估算系统还有多少内存可用的关键指标。所以我的建议是不要被 used 吓到直接看free -h的 available 值。如果 available 持续很小说明内存压力大需要检查有没有内存泄漏或需要优化应用。4.3 网络排查工具ss、ping、traceroute、curl 的组合打法网络问题排查是另一个高频场景。netstat是前辈但现代 Linux 系统更推荐ss速度更快输出更清晰。查看端口监听状态用ss -tlnp-t只看 TCP-l只看监听端口-n不做域名解析加快速度-p显示占用进程。这个命令在端口被谁占了的场景里是绝对主力。类似的还有ss -tunap看所有 TCP 和 UDP 连接的状态以及对应进程排查某个端口连不上或者连接数异常时都很合适。ping、traceroute用于检查网络连通性和路由路径。ping看目标是否能通、延迟多大traceroute能看到数据包一路经过了哪些节点哪一跳延迟异常。注意很多云服务器和防火墙会屏蔽 ICMP 报文所以ping不通不代表服务不可用要用curl或nc再确认下端口通不通。curl -v http://localhost:8080/health可以看 HTTP 请求的具体过程包括 DNS 解析、TCP 建连、TLS 握手、响应状态是排查 Web 服务故障的杀器。复杂场景下还可以用curl -w自定义输出把耗时拆成time_namelookup、time_connect、time_starttransfer等快速定位瓶颈是在 DNS、建连还是服务本身。5. 权限与安全最容易踩坑的几处5.1 chmod 的数字法和符号法权限问题大概是新手在 Linux 上遇到的第一个劝退点。chmod有两种表达方式数字法和符号法。数字法说穿了就是二进制编码读r是 4写w是 2执行x是 1三者相加得到一个 0-7 的数字分别对应 owner、group、other 三组权限。比如chmod 755 file7 给属主读写执行5 给组用户读执行5 给其他用户读执行。这种写法简洁直观是配置脚本可执行权限时最常用的。但数字法有个隐患它把三个组一视同仁地设置你想只给属主加执行权限不动其他权限用数字法就得把完整的三位数重新算一遍。这时符号法更灵活chmod ux file表示给属主加执行权限chmod g-w file表示去掉组用户的写权限chmod or file表示把其他用户的权限设为只读。其中u、g、o、a分别代表属主、组、其他、所有。我在实际脚本里经常用符号法做局部权限调整因为它表达的是改动意图而不是最终状态。还有一个坑是chmod -R递归修改权限。如果你对一个大目录执行chmod -R 777不只是目录下所有文件的权限都被改了而且这些改法通常是无脑地把所有文件都变成所有人可读可写可执行。这在生产环境是严重的安全隐患。正确的做法是区分文件和目录目录需要x权限才能进入文件通常不需要x。所以更安全的递归改法是chmod -R urwX,gorX注意是大写 X表示目录和已有执行权限的文件才加执行位或者用find结合-exec分别处理目录和文件。5.2 chown 与 umask 的配合chown修改文件属主和属组常见用法是chown user:group file。排查文件明明有权限为什么我不能写时先看属主属组是不是自己的。很多情况下文件是从别的地方复制过来的cp命令默认保留原文件的属主和权限结果你复制到自己的目录下文件依然是别人的属主写不进去。这时需要chown 你自己:组 file。另外chown -R同样要慎用它会递归改变整个目录树的属主用之前先想明白级联影响。umask是另一个容易被忽略的概念它决定了新建文件的默认权限。umask 022表示默认创建的权限是 777 减去 022即 755通常目录是 755文件是 644。如果系统设置了比较保守的umask 077那创建出来的文件默认只有属主自己能读写写脚本时如果没注意这点可能别的用户根本读不了你创建的文件。所以我习惯在写脚本前用umask命令确认当前值别让默认权限跟预期不符。5.3 sudo 配置与安全习惯sudo是日常使用频率很高的命令但配置sudoers文件是个精细活一个格式错误就可能让整个系统的 sudo 失效。我一直遵循几条铁律第一配置文件改完一定要先执行visudo -c做语法检查确认没问题再退出。第二尽量不用sudo直接编辑系统文件而是先cp备份改完再校验。第三不要轻易给用户配置 NOPASSWD 权限虽然免密对脚本自动化很好用但安全影响也很大——如果用户的账号沦陷所有 root 权限等于直接暴露。在自动化场景中我倾向于单独建一个用于特定操作的账户授予最小范围的 sudo 权限而不是一股脑加进wheel组。还有一个经验是日常操作不要动不动就sudo。能用自己的账号解决的问题就不用 root 权限。这既是安全习惯也是排查问题的思路——一旦你用sudo掩盖了权限问题的根源后面部署到权限受限环境时又会踩一遍坑。6. 组合实战把命令串起来解决真实问题6.1 日志分析场景从报错到根因只需要三步真实的故障排查从来不是一条命令搞定而是一个由若干命令组合起来的流程。我拿一次典型的日志分析举例服务报警说接口错误率异常上升。第一步我先定位日志文件和时间窗口用ls -lah /var/log/app/找到最新的日志文件用tail -n 1000 app.log看最新的日志内容确认错误确实发生、大概是什么错误类型。第二步用grep -c ERROR app.log统计错误总数再对比正常时段的数值确认是否异常增长。如果确实增长继续组合命令找到具体报错模式grep ERROR app.log | awk {print $5} | sort | uniq -c | sort -rn | head -20假设日志格式里第五个字段是错误码这条命令能告诉你哪个错误码最多。如果第五字段是异常类型那就是哪个异常类最频繁。这一步能快速把排查范围从整个日志缩小到某一种错误。第三步针对那类错误再去取它的上下文。grep -A 5 OutOfMemoryError app.log可以打印匹配行及其后五行这样你能看到完整的堆栈信息。如果报错有时间规律还可以用grep 2025-07-21 10: app.log | grep ERROR | wc -l分时段统计判断是否与某个定时任务或流量高峰相关。整个过程看起来很长实际操作时间通常不超过三十分钟——前提是你熟悉命令的组合方式。6.2 批量文件操作find tar 配合安全搬迁再举一个批量操作的例子。假设生产环境有一万多张小体积的图片文件散落在/data/images/下现在要迁移到另一个目录并打个包。直接用cp -r看似简单但上万次 IO 会让服务器负载飙升。更稳定的做法是先用tar打包再搬迁压缩包然后在目标机器解包。tar -czvf /data/backup/images_$(date %Y%m%d).tar.gz -C /data images注意-C /data images的作用切换到/data目录再打包images子目录这样解包时不会多一层/data/images的路径前缀避免在其他机器解包时目录结构混乱。如果要分批处理还能结合find按时间范围筛选find /data/images -type f -mtime -7 -print0 | xargs -0 tar -czvf recent.tar.gz只打包最近七天修改的文件。对于只想迁移部分文件的需求这种组合比无脑cp可控得多。还要强调一下批量操作前一定要先看预览效果。find /data/images -type f -mtime -7 | head先看看会匹配多少文件确认数据范围没错再执行打包。批量删除、批量改名这些不可逆操作更要在临时目录先做一次排练。6.3 快速定位服务故障top 配合 ss 秒级排查最后分享一个我常用的服务故障排查流程。当你接到报警某某服务不能访问别急着去看代码先用 30 秒做一次系统层排查。第一句df -h确认磁盘没满。第二句free -h确认内存没爆。第三句ss -tlnp | grep 8080确认服务端口是不是还在监听。第四句ps aux | head | ps aux --sort-%cpu | head确认进程是否在、CPU 是否异常。如果端口还在监听但外部访问不了那就可能是防火墙或负载均衡的问题可以用curl -v从本机访问一次再在客户端机器上telnet 目标IP 端口或nc -zv 目标IP 端口一步步缩小问题边界。这套流程的意义在于它让你在最短的时间内把一次故障原因从无法访问这个模糊描述缩小到一个具体的系统层级。后面无论是看日志还是查代码你都有了明确的排查方向。我带的很多新同事刚开始遇到问题时总喜欢直接翻日志找异常堆栈结果堆栈里什么都看不出来——因为问题根本不在代码层而在磁盘写满导致的进程假死。所以系统命令这套基本功怎么强调都不过分。7. 收尾几个值得长期坚持的命令习惯文章写到这儿已经很长了但我觉得最后这些经验比前面所有命令都重要。第一任何不可逆操作前先备份和预览。这句话我在文中重复了很多次因为它真的是我踩过最多次的坑尤其是rm -rf配合变量使用的时候变量为空就等于你把整个根目录删了。如果你的脚本里不得不出现rm -rf记得在变量外套一层保险rm -rf ${TARGET_DIR:?}这样变量为空时命令会报错而不是执行。第二别怕看 man 手册但别只看 man 手册。man是命令发音的权威来源但它的表述往往过于简洁。真正帮你记住命令参数的是你在实际场景中反复使用、反复踩坑的过程。所以我的建议是把man当作查询工具遇到不确定的参数随时man一遍然后把日常高频使用的命令组合记录成一个小笔记或脚本片段。时间长了这些碎片会自然沉淀成你的技能库。第三多练多想。建议你找一台测试机把文中提到的每条命令都照着敲一遍然后故意制造一些异常场景比如删一个不存在的文件、找一个不存在的路径看看报错信息长什么样。命令行的功底不在于你背了多少而在于你面对报错时能不能淡定地读懂错误信息然后立刻想到下一步该敲什么。遇到不会的命令也先别急查答案用--help或-h看看选项多半能自己琢磨出来。这条路没有捷径但走起来绝对值得。我个人这些年最大的体会是Linux 命令就像一门手艺它真正帮你节省的不是某一秒钟的敲击次数而是面对未知系统问题时的那份从容和笃定。希望这篇分享也能给你带来一点这样的踏实感。