1. 为什么命令总是学了就忘——先搞懂Linux命令的学习方法在带过好几批实习生和刚转行的运维新人之后我发现一个特别普遍的现象大家不是不努力而是努力的方向不太对。见过不少同学拿着厚厚的命令手册从第一页开始背背到第三十页就放弃了因为前面的命令压根没机会用。也见过有人把上百条命令抄在笔记本上最后真正记住的只有ls、cd和grep。先说结论Linux命令不是靠背的是靠“场景”驱动的。你不需要掌握几千条命令实际上一个合格的运维或后端开发者日常高频使用的命令可能就五六十条能熟练用好这五六十条就已经能覆盖工作中绝大部分需求了。剩下的命令知道“存在”即可——等真遇到那个场景你自然会去查查两次就记住了。这个标题叫“Linux命令速查宝典”但我不会把它写成一本按字母排序的命令字典那是man手册该干的事。我在这里想分享一套我自己这些年实践下来觉得最有效的分类学习法以及每个类别里那些“高性价比命令”的实战用法。学完这套东西你会发现自己遇到问题时不再是一脸懵地乱敲命令而是能快速定位“这属于哪一类问题该用哪一类命令”。先给一个小建议不要试图一次学完所有命令。我建议把命令按“生活场景”分成几个板块——文件操作、进程管理、文本处理、网络排查、权限控制。每一块先用一天到两天时间集中练熟练的时候也别死记参数就拿着真实问题去练。比如学文件操作那两天就真的去整理一个目录结构混乱的文件夹学进程管理就真的去找一个占用CPU过高的程序并把它处理掉。这样练完基本不会忘。接下来我按这个思路把高频命令分类拆解每一类都会讲清楚“为什么用这个命令”“它的核心参数怎么理解”“有什么坑是新手容易踩的”。这些内容都是平时大家问我最多的问题我尽量用直白的话讲明白。2. 文件定位、批处理与权限控制——高频场景里的关键命令实战2.1 find命令不仅仅是在目录里找文件很多新手学find的时候只记住了find / -name xxx然后遇到权限报错就不知所措或者觉得这个命令又慢又不好用。其实find的真正强大之处在于它支持按任何文件属性进行搜索然后直接对结果执行操作。我举个例子你自己试一下就明白了。假设你想找出某个目录下所有超过500MB的日志文件然后清理掉它们大多数人第一反应是先du -sh *看看谁大再手动删。但用find一行就能搞定find /var/log -type f -size 500M -name *.log -exec rm {} \;这里的关键点有两个。第一-size 500M表示文件大小大于500MB注意M是大写第二-exec ... {} \;的作用是“对每一个匹配的结果执行后面的命令”{}是当前文件名的占位符\;是结束符。很多新手会漏掉这个结尾的分号结果就是报错。还有一点需要注意如果文件名里有空格{}需要加上引号写成{}更稳妥的写法是在-name条件后面直接跟-deletefind /var/log -type f -size 500M -name *.log -delete这个-delete在不涉及复杂处理时比-exec rm更安全但前提是你已经确认过滤条件足够精确。再分享一个高频但容易被忽略的技巧find配合mtime按修改时间找文件。比如要清理三个月前的备份文件可以这样find /backup -type f -name *.tar.gz -mtime 90 -exec rm {} \;这里90表示“超过90天”如果是-90就是“90天以内”。记住这个正负号的逻辑很多类似的命令比如-size、-atime都是同样的规则。2.2 文件统计与磁盘占用的正确姿势du和df是两个名字很像但用途完全不同的命令我见过不少人混用。简单记df看的是“整个文件系统还剩多少空间”比如你的根分区/还剩多少du看的是“某个目录底下到底占了多大空间”。排查磁盘满的问题时我一般分两步走。先用df -h看是哪个分区满了再用du -h --max-depth1 /某个目录逐级往下钻找到是哪个目录最占空间。举个例子df -h du -h --max-depth1 /var | sort -hr | head -20第二行命令的意思是把/var底下第一层子目录的大小列出来然后按人类可读的大小排序取前20个。--max-depth1这个参数特别重要如果不加du会递归统计所有子目录输出结果会非常长而且会额外消耗不少时间在大目录上。还有一个性能陷阱值得提醒du是对整个目录树逐文件统计如果目录特别大比如几百GB的对象存储挂载点执行时间会很长看起来像卡住了。这时候加个-s参数只汇总当前目录、不进入子目录打印每个明细速度会快很多。2.3 权限和用户从“为什么我不能执行”说起权限这块最经典的报错就是Permission denied。我遇到过好几次这样的情况某同学给脚本加了chmod 755也确认了所有者和组都没问题但执行的时候还是报权限不足。后来发现原因很简单——脚本第一行是#!/bin/bash这行没毛病但他把脚本放在了一个没有执行权限的挂载点上比如某个noexec的挂载分区无论文件本身怎么改权限都没用。排查这类问题先看三件事文件权限ls -l、所在文件系统的挂载选项mount | grep 挂载点、以及 SELinux 或 AppArmor 是否拦截ausearch或dmesg | tail。从经验来看前两个问题是九成情况的根因。读写权限的实用场景中需要记住chmod三种表达方式数字方式chmod 754 file对应rwxr-xr--。7421rwx541r-x4r。符号方式chmod ux file给当前用户加执行权限chmod -R gw dir给同组用户递归加写权限。掩码方式umask决定了新建文件的默认权限。系统里默认 umask 通常是 022意味着新建普通文件默认是 644。关于umask多说两句很多新手不理解为什么刚建的脚本总是没有执行权限、每次都要手动chmod x。这其实不是系统在为难你而是默认安全策略故意不给你执行权限。如果你在个人开发环境里嫌麻烦可以把umask 002写进~/.bashrc这样新建的文件权限会变成 775但如果是生产环境我不建议这样改保持默认更安全。2.4 软链接和硬链接别再傻傻分不清ln命令看起来简单但软链接和硬链接的区别经常把人绕晕。我用一句话说明白软链接是一个“快捷方式”它存的是目标的路径字符串目标删了它就成了死链硬链接是同一个文件数据的另一个名字相当于多个目录项指向同一个inode只要还有一个硬链接存在文件数据就不会被删除。实操中用的最多的是软链接比如把某个应用的日志目录链接到独立数据盘ln -s /data/app-logs /var/log/myapp这样应用写入/var/log/myapp实际落盘在/data/app-logs目录空间大了、迁移也方便。硬链接有它的限制不能跨文件系统链接目录也不行。它最大的用处是做“即时一致性快照”式的备份。比如ln /etc/nginx/nginx.conf /backup/nginx.conf.bak这条命令不会复制文件内容只是给同一个数据加了个名字瞬间完成不占额外空间。等下次改了配置、需要回滚时直接覆盖回去就行。有个检查技巧ls -l输出中硬链接的文件权限位后面那个数字表示链接数。普通文件通常是1你每创建一个硬链接这个数字就加1。如果你发现配置文件链接数超过1说明有别的地方还在引用它删之前要想清楚。3. 进程、内存与磁盘排查——定位系统问题的三步套路3.1 排查CPU飙高从top到定位进程的完整链路系统卡了第一反应是看top这没错。但top看的是瞬时快照而且默认按CPU排序信息比较粗糙。我更推荐按内存占用来排查的顺序和思路。先说top里最容易被误解的字段。很多新手盯着%CPU看发现有个进程CPU占用100%就觉得是它把机器搞卡了。但别忘了看load average这个值才是系统整体负载的关键。三个数分别代表过去1分钟、5分钟、15分钟的平均负载。如果1分钟值比15分钟值高很多说明负载正在快速上升反过来如果1分钟低而15分钟高说明高峰已经过去系统正在恢复。定位到可疑进程后下一步是看它的线程和堆栈。top -Hp pid可以查看该进程内所有线程的CPU占用适合处理Java或Python这类多线程应用。想更近一步用strace -p pid跟踪系统调用或者用gdbattach 上去看栈。这两招在实战中非常有用比如某应用卡在等待网络IOstrace里会反复出现poll或connect调用。还有个小工具可能很多人没注意pidstat。它属于sysstat包可以按进程打印CPU、内存、IO的统计信息而且能输出到文件用于事后分析。一条典型的用法pidstat -p pid 1 10意思是每秒采样一次共采样10次。这比top的两个刷新间隔之间的数据更适合用来判断CPU占用是持续性的还是瞬时峰值。3.2 内存排查free的输出你真的看懂了吗free -h输出的信息里used那一列经常让人误判。其实Linux的内存管理哲学是“空闲内存不如拿去缓存”所以buff/cache占了一大块并不代表内存不够用。真正需要关注的是available这一列它才是“在不触发大量换页的前提下还能分配给新进程的内存量”。如果发现available数值持续走低甚至si和soswap in/out持续有IO说明内存严重不足系统正在把内存页换到交换分区。这种情况下最直接的办法就是找到内存大户看是谁在吃内存ps aux --sort-%mem | head -15这条命令按内存占用排序一次列出前15个进程。另外top里按M键也可以切到按内存排序。排查内存泄漏时光看进程的RES常驻内存是不够的因为进程可能已经把内存还给glibc分配器但没有归还给操作系统导致你看RES一直不降。这种情况下可以观察进程的%MEM是否持续稳定增长或者用valgrind这类工具做更深入的内存分析。从我的实践来看很多所谓的“内存泄漏”其实是日志框架或者对象缓存机制导致的老年代增长不一定真是bug。3.3 磁盘IO排查响应慢不一定是因为CPU有时候系统负载不高、CPU也很空闲但应用就是响应很慢。这时候要查磁盘IO。iostat -x 1命令可以看每块盘的详细指标重点看%util和await。但有个容易出错的地方%util100%并不一定代表磁盘“满了”如果底层是SSD即使%util100%也可能因为IO合并机制而吞吐量并不低反过来某些高并发小IO场景下%util不高但await很高那才是真正的延迟瓶颈。定位到是哪个进程在疯狂读写磁盘可以用iotop。这个工具需要root权限不默认安装。如果是数据库等应用通常表现为持续的写日志或刷脏页这时候要结合应用的配置来判断是正常写入还是异常路径。还有个更隐蔽的情况df -h显示磁盘还有很大空间但应用报“no space left on device”。这通常不是真的空间满了而是inode耗尽。用df -i一看就能发现inode用完了。我以前在一个存放大量小文件的采集服务上踩过这个坑当时清理文件太慢最后直接把整个分区的文件迁移到新目录重建文件系统才彻底解决。4. 文本处理和网络排查——数据管道思维与常用排查手法4.1 grep、awk、sed组合使用的管道思维文本处理是Linux命令的精华所在很多人学完单个命令觉得都会了但一遇到“统计日志里某个接口的平均耗时”这种需求就无从下手。核心问题在于缺少一种“管道思维”把文本处理拆成“筛选→加工→统计”三个环节每个环节用一个命令用|串起来。举个例子日志文件access.log的每一行是这样192.168.1.100 [2025/06/01:10:15:23] GET /api/user/info 200 0.235 192.168.1.101 [2025/06/01:10:15:25] GET /api/order/list 200 1.127需求是统计35秒内/api/user/info这个接口的平均响应时间。两步走grep /api/user/info access.log | awk {sum $NF; count} END {print sum/count}grep先把相关行筛出来然后awk对每一行取最后一个字段$NF在awk里表示“每行的最后一个字段”这里正好是响应时间累加并计数最后在END块里算平均值。这里有个细节值得注意awk默认按空格或制表符分割字段所以每行里的[2025/06/01:10:15:23]这种带空格的]不会影响取最后一列。但如果字段分隔符不是空格比如是逗号aa,bb,cc就需要用-F,指定。比如一个CSV文件第二列是用户名要统计出现了多少次awk -F, {print $2} users.csv | sort | uniq -c | sort -rn | headsort排序后交给uniq -c统计重复次数第二次sort -rn按次数倒序排这套组合拳在处理日志去重、统计Top N时极其常用。sed的主力场景是“替换”和“按行操作”。比如要把日志文件里的所有ERROR替换成WARNsed -i s/ERROR/WARN/g app.log注意-i是直接改原文件这个参数在测试阶段建议别用先用不带-i的方式把输出打印到屏幕检查确认无误后再加。关于-i的细节macOS自带的sed和Linux上的GNU sed对-i的语法略有不同macOS需要写成sed -i s/.../.../g file否则会报错。跨平台写脚本时这个差异非常坑提前踩过的人才知道。4.2 grep 的几个高频参数别只会用“grep关键字”grep最简单的用法确实是grep 关键词 文件但要应付真实场景这几个参数必须掌握-r递归搜索目录下的所有文件。注意如果是二进制文件输出可能是一堆乱码加-I可以忽略二进制文件。-i忽略大小写。排查日志里某关键字时很有用比如搜 “error” 会漏掉 “ERROR”别偷懒不加。-v反向匹配输出不包含关键词的行。比如查看配置里所有被注释掉的行grep -v ^# nginx.conf。-n显示行号。排查问题时没有行号几乎寸步难行。-o只输出匹配的部分而不是整行。比如要统计日志里出现的所有IP地址grep -oE [0-9]\.[0-9]\.[0-9]\.[0-9] access.log | sort | uniq -c | sort -rn | head这里-E表示启用扩展正则表达式。需要注意基础的 grep 默认使用的是基本正则、?等符号需要转义或加-E才能生效这也是新手经常匹配不到内容的原因之一。4.3 网络排查的日常武器ping、curl、ss、telnet网络问题排查的基本盘是ping和curl。ping测的是“主机通不通”curl测的是“端口通不通、服务有没有响应”。很多人把这两者混为一谈但实际上ping走的是ICMP协议很多时候主机能ping通但业务端口连不上原因可以是防火墙丢包也可能是服务根本没起来。我在排查“某个接口连不上”的问题时四步走ping 目标IP— 基础网络是否可达。curl -v http://目标IP:端口/路径— 看TCP握手和HTTP响应是否正常-v参数打印完整过程。telnet 目标IP 端口— 只测TCP端口能否建立连接比curl轻量适合反向排查“服务在听但HTTP层有问题”的情况。ss -tlnp | grep 端口— 看本机这个端口有没有进程在监听。关于curl的几个容易出错的地方访问HTTPS站点时如果目标站点证书有问题curl默认会拒绝连接。排查内部测试服务时可以用-k跳过证书校验但生产环境绝对不要这样写。还有-H头参数调试接口必备比如curl -X POST http://127.0.0.1:8080/api/login \ -H Content-Type: application/json \ -d {username:test,password:123456}ss命令现在基本取代了老的netstat输出更清晰更快。一条实用的命令是看当前所有TCP连接状态统计ss -tan state established | wc -l这条能快速判断系统当前到底有多少活跃连接配合ss -s看汇总信息排查连接数异常增长时非常好用。4.4 查看日志的利器tail、less和journalctl排查线上问题日志是第一现场。tail -f跟日志简直是运维标配但有两个坑。第一如果日志文件被日志轮转重命名比如从app.log变成app.log.1tail -f会继续盯旧的“文件句柄”新写入的内容不会显示。这时候要用tail -F大写F它会按文件名追踪、文件轮转后自动重新打开。这个差异在我第一次踩坑时找了半小时才明白。第二less查看大日志文件时按/搜索关键字按n跳到下一个匹配项按q退出。但如果文件特别大几个GBless打开时也会有一些卡顿。更快的做法是用grep先过滤再输出到临时文件或直接用管道查看或者至少加--no-init参数减少屏幕初始化开销。journalctl是systemd时代的日志管理命令看服务日志特别方便。几个高频用法journalctl -u myservice.service -f # 跟某个服务的实时日志 journalctl -u myservice.service --since 1 hour ago # 看最近一小时的日志 journalctl -u myservice.service -p err # 只看error级别及以上的日志注意-p err表示只看error及以上包含crit、alert、emerg日志级别的过滤对排查问题很有帮助。5. 从速查到工具箱——把自己常用的命令沉淀成速查笔记5.1 为什么你查完命令就忘缺少沉淀机制前面讲了这么多命令和用法但你如果只是“眼睛看会了”过两周还是会忘。我自己的做法是每个项目周期结束后把这次用到的高频命令整理成一份个人速查笔记放进一个专门的git仓库里维护。不追求覆盖所有命令只记录自己真正用过、踩过坑的。这个仓库就是我的“外部大脑”查一次、沉淀一次、长期积累。做笔记有一个重要原则不要只记命令本身一定要把“当时为什么要用”和“踩了什么坑”写上去。比如只记find /var/log -type f -size 500M -delete下次看到还是不知道为什么但如果写“清理日志分区磁盘空间注意先确认匹配条件-delete会直接删文件不可恢复”这段记忆才是可复用的知识。我常用的格式大概是这样的## 磁盘清理 场景/var分区磁盘满应用无法写入日志。 排查df -h确认分区du --max-depth1 /var 找大目录。 操作find /var/log -type f -name *.log -size 500M -delete 注意-delete不可恢复建议先不加-delete跑一次看匹配到哪些文件。这种笔记积累到一定量之后会发现很多问题都是同一个套路的变种查笔记的速度会越来越快。5.2 给自己做一个“命令速查脚本”如果你经常需要在多台机器上执行同样的排查流程可以考虑写一个简单的Shell脚本把这些流程固化下来。我自己有一个sysinfo.sh一键收集系统状态摘要日常巡检时直接看输出结果不用一遍遍敲冗长的命令。脚本核心内容大概是这样的#!/bin/bash echo 系统时间与运行时长 uptime echo echo 内存概况 free -h echo echo 磁盘空间 df -h | grep -vE ^tmpfs|^devtmpfs echo echo CPU/内存占用前10进程 ps aux --sort-%cpu | head -11 echo echo 当前监听端口 ss -tlnp把这段脚本放到/usr/local/bin/目录下加执行权限以后遇到问题先跑一遍基本上80%的常见故障都能看到线索。这个脚本最大的价值不是省几秒钟而是让排查流程标准化。每次先看同一组数据不容易漏掉一些平时不会注意的指标。5.3 给新人的几条红线建议最后聊几条我用“真金白银”换来的教训希望对刚接触Linux的同学有用。第一不要在不确定的情况下使用带-f或-delete的删除类命令。我见过有人为了清理日志写了find / -name *.log -delete结果把一些应用运行依赖的历史日志也删了虽然不致命但恢复很麻烦。安全做法永远是先用不带删除的形态跑一遍确认匹配范围再动真格的。第二线上环境修改配置前养成先备份的习惯。最简单的就是cp file file.bak.$(date %Y%m%d%H%M%S)一条命令把时间戳带上回滚时直接找最近的备份。第三了解自己的环境。不同的发行版、不同的shell、不同的工具版本命令行为可能不一样。比如前面说到的sed -i在Linux和macOS的差异、ss和netstat的新旧替代关系。多留意这些细节能减少很多“照着教程敲却报错”的挫败感。第四学会查man手册和--help。没有人能把所有参数记在脑子里关键不是“记住每个参数”而是“知道某个命令能解决哪类问题然后会查它的具体用法”。我在需要精确知道某个参数含义时最常用的三阶方法是先man 命令看完整文档再命令 --help看速览最后实在不懂就在测试环境里敲一遍看看行为。5.4 从速查到形成肌肉记忆命令的学习曲线不是一个“一直涨”的曲线而是“前期快速积累、中期大量遗忘、后期通过反复使用形成肌肉记忆”的过程。肌肉记忆是怎么来的就是在真实场景里反复用而不是在小本本上反复抄。我个人的体会是每个人都会有一批“能用但不熟”的命令真正熟的永远是最常用的那三五十条。所以与其焦虑“还有多少命令没学完”不如把已经会的这些练到“手比脑子快”的程度。等到查命令的动作越来越少你的Linux基本功就已经过了大多数人水平了。给自己定个小目标吧接下来的两周每天刻意练习一条高频命令把它放进真实场景里用一遍然后在自己的速查笔记里记一条“踩坑/心得”。两周后你会明显感觉排查问题的速度不一样了。