如果你打开过几十台服务器、处理过几次凌晨三点的告警你会发现Linux常用命令这东西其实就两类一类是每天闭眼都能敲的另一类是翻了半天手册才敢用的。这份整理主要来自我在日常开发和系统维护中反复用到、反复踩坑后沉淀下来的内容既覆盖了文件、进程、网络、日志这几大高频场景也把很多命令背后的设计思路讲清楚。这篇文章适合刚入行的开发、运维和测试同学也适合那些已经会用一些命令、但总感觉知识比较零散、遇到问题不知道怎么组合排查的人。我不会只给你罗列一长串参数而是会告诉你每个命令在真实场景里怎么用、什么时候不该用、遇到问题又该从哪条命令入手。废话不多说直接进正文。1. 先把Linux命令的设计思路捋清楚后面会顺手得多1.1 一切皆文件这句话不是口号Linux命令之所以看起来多、记起来乱是因为同一件事往往有好几种做法。但如果抓住内核层面最核心的设计原则——“一切皆文件”很多命令之间的关系就瞬间清晰了。在Linux里磁盘设备、网络连接、正在运行的进程、普通文本统统被抽象成文件。你在 /dev 下看到的磁盘分区是文件/proc 下的进程状态也是文件甚至往终端打印输出这件事本质上也是往一个文件描述符里写数据。理解了这一点你就会明白为什么 grep 可以搜索日志、也可以过滤 ps 的输出因为 ps 的结果本来就是一段文本流为什么重定向能覆盖所有命令因为任何命令的输出都可以当作文件来处理。我见过不少新人纠结于 xx 命令和 yy 命令有什么区别其实它们往往只是同一个文件处理逻辑在不同场景下的具体形态。带着这个思路去学比死记硬背参数有效得多。1.2 命令的组合能力才是Linux真正的杀手锏单个命令能力有限但通过管道符、重定向、变量替换组合起来就能完成很复杂的工作。我常跟同事说不要试图找一个“万能命令”而是要学会把几个小命令像积木一样搭起来。比如你要统计日志里某个接口的报错次数一条命令就能搞定grep awk sort uniq。这种组合能力是Windows命令行无法比拟的也是运维、开发排查问题效率差距的主要来源。这份整理的后续内容里我会反复用到这个组合思路你慢慢会体会到。2. 文件与目录操作每天都要用的命令反而最容易出事2.1 ls、cd、cp、mv、rm的高频细节这些命令大家都会敲但能敲对的人真不多。先说说 ls很多人只知道 ls 和 ls -l其实我日常最常用的组合是 ls -lah。其中 -a 是显示隐藏文件-h 是人性化显示文件大小比如 1.2G 而不是一长串字节数字。排查磁盘占用时这个命令能帮你快速定位哪些目录有问题。cd 没什么好讲的但我强烈建议你掌握 cd - 这个用法它可以在最近两个目录之间切换。实际工作中我经常在一个深层目录和另一个深层目录之间来回操作cd - 能省掉不少键盘敲击。cp 和 mv 是重灾区。首先cp 跨磁盘复制时要用 -a 保留权限、时间戳否则复制过去的文件经常会出现执行权限丢失的问题。mv 在同一文件系统内是瞬间完成的因为它只是改了个目录项但跨分区移动文件本质是复制加删除大文件会非常慢。这些属于原理层面的认知知道了能避免很多莫名其妙的“怎么文件没了/权限变了”的困惑。2.2 最危险的命令rm -rf 的替代方案我必须把 rm -rf 单独拿出来说因为我见过太多次因为这条命令崩溃的场景包括我自己早期也误删过东西。rm -rf / 会删系统rm -rf /var 会删日志rm -rf ./ 配合错误的目录上下文会把整个项目删空。我现在的习惯是尽量不使用原生的 rm 删除重要目录而是为 rm 配置一个别名改成移动到一个临时回收站目录。比如在 .bashrc 里加上 alias rmmv --force $ /tmp/trash这样即使误操作了也能从 /tmp/trash 里找回来。更重要的是在删除之前养成用 ls 先看一眼目录内容的习惯这会救你很多次。2.3 权限和链接chmod、chown、ln的理解权限问题几乎是新手遇到“我明明有文件为什么不能访问”时的主要来源。Linux权限分为读、写、执行三种分别对应数字 4、2、1所以 chmod 755 的意思就是文件属主有全部权限属组和其他人可读可执行。这个映射关系必须背下来面试也常考。chown 则是改变文件属主。我印象最深的是部署应用时报“Permission denied”结果发现是启动用户对目录没有写权限一条 chown -R deploy:deploy /opt/app 就解决了。ln 分硬链接和软链接日常用得最多的是软链接也就是 ln -s。很多应用目录实际是指向另一个分区的软链比如 /data 指向 /mnt/nas_data。用软链接可以灵活调整存储布局但要注意软链接如果指向相对路径移动目录之后会断链这是我在脚本里踩过的一个坑。3. 文本处理与日志检索定位线上问题最快的技能组合3.1 日志检索三件套grep、tail、less日志检索是我在排查问题中最依赖的能力核心命令就是 grep、tail、less。先说 grep它的核心参数我认为是这几个grep -r递归搜索目录下的所有文件。排查代码或配置时我经常在项目根目录执行 grep -r 某个常量 来找引用位置。grep -n显示行号。日志报错只给“第几行”是常规需求没有行号会非常痛苦。grep -A/-B/-C显示匹配行之后/之前/前后几行。异常堆栈通常不止一行用 -A 10 才能看到完整上下文。grep -E启用扩展正则配合管道符同时匹配多个关键词。再配合 excl 参数比如 grep -v 正常业务日志可以快速过滤掉干扰信息。我排查问题时经常同时用多个 grep 嵌套过滤配合 alias 简化成一句话。tail 最常用的场景就是跟随日志输出也就是 tail -f。调试程序时一边在另一个终端触发请求一边盯着日志看到新行滚出来基本就能实时判断程序走向。如果日志文件很大直接 tail -n 50 先看一下尾部最新内容即可不要一上来就 cat 整个文件。less 是我最推荐的日志阅读器。它和 vi 操作有点像可以上下翻页、搜索、跳转。最实用的是在 less 里输入 /关键字 进行搜索按 n 跳到下一个匹配按 G 跳到文件末尾按 g 回开头。排查一个 10GB 的日志文件时用 less 比 vim 效率高很多因为 vim 会把整个文件载入内存大型文件打开很慢。3.2 sed与awk结构化文本操作的两把刀sed 主要用于文本替换和编辑。最常见的用法是 sed -i s/旧内容/新内容/g 文件直接在文件里做全文替换。我改配置文件时经常用这个命令比如统一把 IP 从旧地址改成新地址一条命令完成不用打开编辑器。这里必须提醒-i 直接改写文件操作前建议先备份或者先去掉 -i 跑一遍确认输出无误。我在生产环境吃过亏原本只想替换一处结果正则写宽了半个文件都被改掉还好有备份。awk 的功能更强它默认按空格把一行切成多列常用场景是提取某些字段。比如查看进程端口时用 ps aux | awk {print $2} 可以只列出 PID。更进阶的用法比如 awk /关键字/ 可以筛选行再处理。awk 的完整编程能力很庞大但日常高频的也就是字段切割、条件过滤和简单统计这三板斧。3.3 实战案例5分钟定位接口响应慢的问题我拿一个实际排查过程举例。某次线上反馈“下单接口变慢”我当时的操作顺序是这样的先看应用日志tail -n 200 app.log发现确实有不少超时记录。再用 grep 下单接口 app.log | tail -n 50 筛选出相关日志发现每次调用前都会查询数据库。此时我怀疑是数据库慢查询于是去数据库侧开了慢查询日志定位到一条 SQL顺手查看执行计划发现没走索引。处理方式是加了联合索引接口耗时从 3 秒降到 200 毫秒。整个过程没有用到特别复杂的命令核心就是 tail、grep、管道组合再加上对业务链路的基本理解。很多人遇到问题会手忙脚乱去翻监控平台但实际上本地命令组合往往能更快缩小范围。4. 进程与资源排查从动不动就看top到理解系统发生了什么4.1 ps、top、free、df、du一次说清楚ps 是查看进程快照的命令最常用的是 ps -ef 和 ps aux。前者是标准格式后者带了 CPU 和内存占用率。只看格式你可能会觉得两个差不多但排查资源占用时 ps aux 的排序输出更有价值。我一般配合 sort -k3 -r 按 CPU 排序快速找出可疑进程。top 是动态刷新进程状态的命令它和 ps 的区别是 top 是持续的、动态的适合观察变化趋势。按下 P 按 CPU 排序按 M 按内存排序按 1 查看所有核心的负载。另外我强烈建议关注 load average 的三个数值如果第三个数值持续超过 CPU 核数说明系统处于过载状态。free 查看内存使用重点看 available 而不是 used因为 Linux 会尽量用闲置内存做缓存used 高不代表真的不够。df -h 查看磁盘分区使用率du -sh 加目录名可以看某个目录的总大小。排查磁盘空间被什么占满时我的顺序是df -h 先看哪个分区满了du -sh /tmp/* 或 du -sh /var/* 逐级往下钻直到找到那个占了大量空间的文件或目录。4.2 kill和进程控制不只是kill -9很多人的认知里 kill 强杀进程其实 kill 的本质是发送信号默认发送的是 SIGTERM 信号让进程有清理资源、正常退出的机会。只有进程不响应时才用 kill -9 发送 SIGKILL 强制终止。我见过不少同事一上来就 kill -9结果进程的临时文件没清理导致下次启动报错。正确处理顺序是先 kill 发送温和信号等待几秒观察是否退出不行再 kill -9。对于服务类进程我更推荐尽量用应用自身的优雅关闭命令比如 Nginx 的 nginx -s stop。进程前后台切换也值得掌握CtrlZ 挂起当前任务bg 让任务转后台运行fg 拉回前台。跑一个耗时脚本时我经常先 CtrlZ 再 bg退出终端时脚本也不会被中断——当然更稳妥的做法是用 nohup 或 systemd。4.3 深入排查strace、lsof与调试利器gdb遇到进程卡死、文件被占用等疑难杂症时常规命令就不够用了。strace 可以跟踪进程的系统调用它能告诉你进程执行到哪一步卡住了。之前排查一个应用连不上外部服务的问题我用 strace -p 进程号 看到了它在 connect 系统调用上长时间阻塞一下子就判断出是网络连通性问题而不是应用逻辑问题。lsof 是“list open files”的缩写它最经典的用法是 lsof 被删除的文件名或端口号来查看哪个进程占用了某个端口。每次遇到端口被占用导致服务起不来的问题lsof -i:8080 直接告诉你 PID然后去排查对应进程。还有一个配合技巧lsof | grep deleted 可以查看已被删除但仍占磁盘空间的文件这类场景在日志文件被手动删除但进程仍在写时特别常见。gdb 是C/C程序调试工具虽然日常开发不一定天天用但排查 coredump程序崩溃生成的核心转储文件时是刚需。用法也不算复杂gdb 可执行文件 coredump文件然后输入 bt 查看崩溃时的调用栈基本就能定位到出问题的代码位置。如果你接触的服务是 Go、JAVA 写的则各有对应的排查工具但思路相通都是拿到“出事瞬间的程序状态快照”。4.4 进程间通信的一些命令视角进程间通信IPC在 Linux 里是个大主题常用方式包括管道、消息队列、共享内存、信号量、socket。对应到命令上管道就是前面强调的 |socket 可以用 ss 查看共享内存和信号量可以用 ipcs 查看。我调整过几次系统参数比如提高共享内存上限改 /proc/sys/kernel/shmmax 之类。改这类参数前先确认当前进程是否真的会用到不然调整意义不大。曾经有个系统频繁崩溃用 ipcs 看发现共享内存段没有正常释放定位到某进程异常退出时没做清理后来在代码里补了清理逻辑才解决。5. 网络排查与远程操作连不上、响应慢、文件传不动怎么办5.1 连通性判断从ping到ss到nc排查“连不上”这个问题的标准流程我是这样做的。先 ping 目标主机看网络层是否通再 telnet 目标IP 端口 或 nc -vz 目标IP 端口确认端口是否监听最后 ss -lntp 查看本地监听端口和对应进程。通过这三层基本能把问题定位在网络不通、防火墙拦截、端口未开放还是服务没起来。ping 不通不代表服务一定有问题很多机房会禁 ping。此时用 tcping 或者 nc 直接探测端口更靠谱。telnet 在很多新系统里默认不安装了所以 nc 可以当备选方案。ss 是 netstat 的替代者输出更快-l 显示监听端口-n 不做域名解析-t 只看 TCP-p 显示进程名。每次都要把它们合在一起用ss -lntp。5.2 用curl测试接口比浏览器好用得多curl 是排查 HTTP 接口问题的必备工具常用参数curl -v显示完整请求和响应头是调试的首选方式。curl -I只获取响应头快速判断服务是否返回 200。curl -X POST -d 参数 URL发送 POST 请求。curl -o /dev/null -s -w %{http_code}\n只输出状态码适合批量检测。我在定位线上接口返回 502、504 时就靠 curl -v 看是连不上上游还是上游超时。配合 time_total 字段还能测量接口耗时比手动掐表靠谱得多。5.3 文件传输与同步scp、rsync、wget机器之间传文件我首选 scp简单直接scp 文件 user主机:目录。传整个目录加 -r。但如果你要同步到多台机器、断点续传、增量同步rsync 才是正解。rsync -avz 源 目标 是经典组合-a 归档模式保留权限和时间戳-v 显示过程-z 传输时压缩。rsync 还支持通过 -e 指定 ssh 端口比如 rsync -e ssh -p 2222。下载文件用 wget 或 curl -O。wget 支持断点续传-c 参数下载大文件非常方便。平时下载安装包、配置文件时我习惯先把 URL 固化到一个脚本里省得天天翻浏览器。5.4 挂载NAS与磁盘空间管理热搜词里有“linux 挂载 nas 存储”这部分操作确实经常遇到。挂载 NAS 的基本流程并不复杂先创建挂载点目录然后用 mount -t nfs 服务IP:/共享路径 /挂载点 挂载最后在 /etc/fstab 里加一行保证重启后自动挂载。这里最大的坑是网络不通或者防火墙限制挂载时报 mount.nfs: Connection timed out 时大概率要检查网络和端口。另一个坑是 fstab 配置错误导致重启起不来我每次改完 fstab 都会先执行 mount -a 试挂载一次没问题再重启。磁盘分区相关的命令比如 fdisk、mkfs、blkid 也顺带提一下。新增加一块磁盘时常规流程是lsblk 看识别没识别到fdisk /dev/sdX 分区mkfs 格式化成 ext4 或 xfs最后挂载并写入 fstab。这套流程做完新磁盘就能正常使用了。虽然云服务器一般都帮你处理好了但自建机房、离线环境经常要走这一趟。6. 高频命令组合与我的工作流把常用操作固化成肌肉记忆6.1 用别名和脚本把每天敲的命令收窄到了这个阶段你要考虑的不是“还能会多少命令”而是“哪些命令我每天都在敲、值得固化成别名”。我的 .bashrc 里长期保留着这些别名注意别名定义里不要加过于复杂的逻辑简单映射就好。复杂的直接写脚本放到 /usr/local/bin 下全局可用。alias llls -lt按时间排序看哪个文件今天改过。alias grepgrep --colorauto高亮匹配关键字。alias portsss -lntp快速查端口占用。alias dfdf -h默认把磁盘占用显示成人能看懂的大小。alias du1du -h --max-depth1只看一级目录的大小。这些别名看起来不起眼但每天省下的是大量重复输入。有过几个月经验之后你会发现真正高频的命令不超过二十条剩下的都是遇事才查。6.2 用一个完整的日志排查流程演示“组合拳”拿一次 MySQL 磁盘空间告警来串联整篇内容我收到告警后先 df -h 看哪个分区满了发现 /var/lib/mysql 所在分区使用率 100%。再用 du -sh /var/lib/mysql/* 逐级定位发现 binlog 日志目录占了大量空间。此时先用 ls -lt 确认哪些 binlog 是最新的确认没有外部业务正在读取后执行 PURGE BINARY LOGS 清理过期 binlog空间马上释放。整个过程用到的命令就是 df、du、ls以及 MySQL 客户端指令。看起来都很基础但关键在于按顺序排查、每一步都有目的。这种工作流意识是区分新手和熟练工的关键。6.3 sudo的使用边界与“提权”相关的安全意识热搜里有“linux 提权”我多说几句。提权这个词在安全领域有两面性对攻击者是漏洞利用对系统管理员是权限管理。我现在的原则是尽量用普通账号登录需要管理员权限时用 sudo 执行单条命令而不是直接 su 成 root 然后一顿操作。sudo 配置在 /etc/sudoers 里可以用 visudo 编辑。很多团队会给运维账号配置 ALL(ALL) ALL 这种全量权限但如果你自己管理个人服务器我建议针对高频命令做最小授权比如只允许重启某个服务、查看某些日志。不要随便赋予全部权限避免账号被攻破后一路畅通无阻。执行 sudo 命令前先想一下这条命令真的需要 root 权限吗比如改自己的文件和查看系统负载都不需要 root。另外尽量不要在网上下载不明脚本然后直接 sudo bash 执行。我见过有人为了图方便从网上复制了一段“一键安装”脚本结果里面夹带私货把系统配置改得面目全非。安装软件优先用发行版自带的包管理器比如 apt、yum、dnf从官方源安装。7. 踩过的几个坑与学习路径建议7.1 完整的踩坑记录我在生产环境误删文件之后做了什么那次经历让我养成了很多习惯。某次执行清理任务时我原本想清理项目旧日志命令写成了 find /opt/app/logs -name *.log -mtime 30 -delete结果因为目录上下文没切对它把另一个目录下的重要备份文件也连带删了因为备份文件也匹配了 *.log 且修改时间超过 30 天。发现后的第一时间是停止写入操作避免被删数据被覆盖。然后立刻用 extundelete 尝试恢复对应分区但恢复并不完整最终靠 git 仓库和备份重新生成了数据。那次之后我的清理脚本都加了两层保护一是先运行 find 不带 -delete只打印匹配文件清单人工确认二是所有删除动作都移到 “过期数据统一归档到 /tmp/backup 再二次清理” 的流程。这个教训换来的经验就是任何批量删除一定要分成“先看、再删”两步脚本里加上确认机制。7.2 像排查案件一样排查系统故障系统故障案例看多了我发现高手和普通人的区别不是知识面差异而是排查思路的差异。高手的排查方式很像侦探办案收集线索、形成假设、验证假设、缩小范围。比如系统突然变慢新手可能直接执行 reboot高手会先看 uptime 看负载再结合 dmesg 看内核日志然后查是 CPU 高、内存不足、磁盘 IO 慢还是网络抖动。每个环节用到的命令都很基础但需要有一条清晰的逻辑链。我建议你现在就可以尝试模拟一个故障环境故意让某个进程卡住然后用 ps、top、strace 一步步推演多练几次排查能力会有质的提升。7.3 进阶路线从“记住命令”到“理解系统”到了最后我想聊聊怎么继续往上走。命令本身是死的但系统是活的。当你发现自己不再需要背参数而是能够根据需求“猜”参数时就说明已经进入下一个阶段了。后续可以学习 shell 脚本、systemd 服务管理、容器与 Docker、K8s 的基本操作这些的基础仍然是底层命令。比如 docker 常用命令里的 docker ps、docker logs、docker exec本质就是对进程和日志的管理换了一层壳而已。掌握底层逻辑后上层工具学起来会非常快。还有一个建议是多看系统自带文档。man 命令虽然打开像天书但遇到不确定用法时它是最权威的参考。查陌生命令时先 man 一两分钟再自己写一个小用例验证比到处搜博客可靠得多。如果你平时用 Linux 做开发推荐刻意练习每个命令的“管道版本”比如把 ps 和 grep 组合起来找进程把 tail 和 grep 组合起来盯日志把 find 和 -exec 组合起来批量操作。这些组合熟练之后很多看起来复杂的运维操作其实就是两三条命令搞定的事。最后分享一个我的个人习惯我会在本地维护一个 markdown 文件专门记录自己遇到过的命令场景按“问题-命令-备注”的格式写。时间久了这就是属于你自己的命令手册比网上任何现成大全都顺手。Linux 命令的整理和积累也不是一次性的任务它会随着你遇到的场景不断变厚而这个慢慢充实的过程本身就是系统能力提升的最好见证。