"当时那一幕我记得特别清楚，周一刚上班就有同事在群里喊系统响应慢，一堆人围在一起盯着终端，半天没人说话。有人敲了个ps -ef | grep java，发现Java进程还在，又敲了个free -h，看到内存也没满，就卡住了。我过去直接输了三行命令：top -Hp PID看线程，jstack PID抓线程栈，再加上一条grep -A 20 "nid="过滤，三分钟定位到是某一个线程在死循环——对方当场愣住，问我平时是不是把Linux常用命令大全背下来了。"
其实真不是背出来的。我是把命令按场景和语义串起来记的，这次趁着整理《Linux系列》第六篇，把平时最常用、面试最爱问、运维最容易用到的Linux常用命令从头到尾捋了一遍，包括每个命令背后的原理、常见的坑，以及不同场景下应该怎么组合使用。这篇文章适合刚入行的运维、日常要碰服务器的后端开发，以及准备Linux面试题的求职者，当然如果你已经在用Linux但想补一补"为什么这么用"的逻辑，也值得读完。
1. 别急着背命令，先建立Linux命令的"语义地图"
很多新手学Linux命令最大的问题是"背了忘、忘了背"。今天记了chmod明天就忘，后天看到awk直接劝退。我自己的体会是：命令数量看似多，但核心就几十个，关键在于先搞懂命令的底层结构，再按使用场景去归类记忆。
1.1 命令的基本结构：程序、参数、管道
Linux命令长的样子其实都是同一个套路——命令 + 选项 + 参数。比如ls -l /home这条命令里，ls是要执行的程序，-l是选项（通常用来改变输出格式或行为），/home是参数（告诉程序要操作的对象）。这个概念虽然简单，但很多人学了一堆命令后反而忽略了它，导致遇到没见过的命令时不会举一反三。
我见过不少人在命令行里卡住的真正原因，不是命令记不住，而是不理解两个关键概念：
- 一切皆文件。在Linux里，硬盘、网卡、终端、进程信息都以文件形式暴露在
/dev、/proc这些目录下。理解了这一点，很多命令的用法就能迁移。 - 管道与重定向。
|把前一个命令的输出接到后一个命令的输入，>把输出写入文件。这是Linux的"组合拳"机制，单条命令解决不了的问题，用管道把两三条命令串起来，效果比GUI点半天还快。
所以我不建议一开始就去啃那种几百页的命令手册。先把手头最常用的20个命令用熟，理解它们的输入输出是什么，再通过管道把它们拼起来用，效率会高很多。
1.2 按场景归类：运维、开发、嵌入式各有侧重
命令虽然通用，但不同岗位的关注点完全不一样。做Web运维的，top、ss、tail、journalctl是每天的日常；做后端开发的，git、grep、find、systemctl用得最勤；做嵌入式开发或者车载相关的，可能整天在和dmesg、ifconfig、adb打交道；面算法和架构岗的，反而更常被问到curl、jq、awk这类数据处理命令。
我理解很多人看那些"Linux常用命令大全"时候的迷茫——几百个命令平铺下来，不知道从哪下手。我的经验是：先确认自己的领域，再从"必会清单"开始，用到哪补到哪。比如我刚工作那会做PHP项目，最常干的事情是看日志、重启服务、查进程，所以最先吃透的是tail、grep、systemctl、ps、kill这五个命令；后来开始处理前端构建和容器化，才慢慢补上scp、rsync、docker。命令不是一次学完的，是跟着场景长出来的。
2. 高频必会命令：文件操作、权限与文本处理
不管什么岗位，文件操作和文本处理都是Linux的万能基础。这部分的命令我用得最频繁，也最容易看到别人踩坑，单独拎出来详细讲讲。
2.1 文件与目录操作：这些基础命令的隐藏细节
ls、cd、pwd、mkdir、rm、cp、mv这些基础命令几乎每天都要敲，但很多细节值得留意：
ls -lh里-h会自动显示人类可读的大小单位，平时看文件大小一定要带上，不然一个数字竖排出来很难受。ls -lt按修改时间排序，排查"哪个文件刚被动过"时非常有用。rm -rf是新手翻车重灾区。我见过有人写rm -rf $DIR/，结果环境变量没赋值，命令变成rm -rf /，还好及时发现才没酿成大祸。我的个人习惯是：变量路径先echo确认，再用rm；能加-i交互确认就加。cp -r拷贝目录时必须带-r，不加会直接报错。拷大型目录建议用rsync而不是cp，它支持断点续传、增量同步，而且可以通过--progress看到进度，传数据更安心。mv在跨文件系统时会先复制再删除，速度慢且占用临时空间，大量移动文件时，可以先用df -h确认源和目标是不是同一个分区，不同分区建议改用rsync传输后清理。
# 查看当前目录下所有文件的大小，按从大到小排列 ls -lhS # 复制目录并显示进度 rsync -avh --progress /data/app/ /backup/app/ # 安全删除文件的习惯：先打印路径确认 echo $APP_DIR rm -rf "$APP_DIR"2.2 权限与用户：chmod、chown 和 sudo 的原理
Linux是多用户系统，权限体系里三个核心概念是：用户（user）、用户组（group）、其他人（others）。ls -l输出的第一个字段就是权限位，比如-rw-r--r--这串字符，第一位是文件类型（-表示普通文件，d表示目录），后面每三位一组，分别对应用户、组、其他的读（r）、写（w）、执行（x）权限。
chmod的两种用法是新手容易混淆的：数字法和符号法。数字法用r=4、w=2、x=1相加，比如chmod 755 file表示用户可读可写可执行、组可读可执行、其他人可读可执行，这是最常见的设置；符号法用u+x、g-w、o=r这种形式，适合只改某个角色的某类权限。我个人习惯用数字法，因为它更直观，几条命令排在一起不容易乱。
chown用来修改文件归属，比如把/data/app的所有者改成www用户，命令是chown -R www:www /data/app。注意-R才会递归处理目录下所有文件。sudo的原理是提权执行，配置文件在/etc/sudoers，平时用sudo时要克制，能不加sudo就用普通用户操作，因为 root 权限下一行错误的rm可能炸掉整台机器。
# 为脚本添加执行权限 chmod +x deploy.sh # 修改目录归属，并设置 setgid 位，使新文件自动继承组 chown -R www:www /var/www/html chmod g+s /var/www/html # 查看当前登录用户及身份 id whoami2.3 文本处理三剑客：grep、sed、awk
这三个命令是Linux排查问题的核心武器，也是面试必考的内容，值得多花点时间。日常使用中，它们各自擅长的事不一样：grep用来筛选，sed用来替换和编辑，awk用来按列处理和统计。
grep最常见的场景是过滤日志。我在排查线上Nginx错误的时候，典型的操作是：
grep -i "error" /var/log/nginx/error.log | grep -v "favicon" | tail -100这条命令的意思是：过滤出包含error的行，忽略大小写（-i），排除掉favicon相关的噪音（grep -v），只看最后100行。排查接口报错时，还会加上--color=auto高亮关键词。grep -r可以递归搜索目录，适合在代码里定位某个配置项；grep -E支持正则表达式，复杂匹配靠它。
sed最常用的是-i做原地替换。举个例子，要把配置文件里的旧IP换成新IP：
sed -i 's/192.168.1.100/192.168.1.200/g' /etc/app/config.properties这里s是替换命令，g表示全局替换。注意不同发行版的sed -i参数有差异：GNU版本（Linux自带的）直接用sed -i，BSD版本（macOS自带的）需要sed -i ''，这就导致同一行命令在本地Mac上跑不起来。后来我统一在Linux服务器上执行，或者在Mac上写脚本时直接加上空参数。
awk是三个命令里门槛最高的，但也是威力最大的。我常用它处理日志统计，比如分析Nginx access log里哪些IP访问最多：
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20这条命令把每行日志按空格拆分，取第一个字段（即IP），sort排序后uniq -c统计次数，再按数字大到小排序，取前20个。awk还支持条件判断和循环，比如筛选耗时超过3秒的请求：
awk '$NF > 3 {print $0}' /var/log/nginx/access.log这里的$NF表示最后一个字段，假设日志最后一列是响应耗时。要筛选状态码为500的记录，用awk '$9 == "500"'。这类一行式命令在排查性能问题时非常方便。
3. 系统与运维排查场景：日志、进程、网络与磁盘
基础命令熟手之后，真正的挑战来了——线上出了故障，你该怎么用命令定位?这是运维和面试考查的重点，我把日常排查的几个核心场景拆开讲。
3.1 日志搜索实战：怎么从海量日志里快速找到问题
排查线上问题第一件事就是看日志。日志文件动辄几个G，千万别用cat去读——终端直接被刷爆，而且会占用大量IO。我的顺序是：先tail -n看尾部最近记录，再用grep过滤关键词，偶尔用less上下翻看，配合/关键词搜索。
tail -f是排查实时问题的利器，比如压测时观察日志是否还继续输出，用tail -f app.log挂着看。我自己比较常用的是tail -f | grep keyword组合，只把有关键词的日志实时打印出来，避免无关输出刷屏。
在systemd的机器上，journalctl逐渐取代了传统的日志文件查看方式。查看某个服务的最近50条日志：
journalctl -u nginx -n 50 --no-pager--since "2025-01-15 10:00"可以指定时间段；-f等同tail -f实时跟踪。这个命令在排查"服务起不来但没留下传统日志"的情况时特别好用，systemctl status只给三行摘要，完整日志还得靠journalctl -u 服务名。
排查日志时有个常见问题：时间不同步。服务器时钟偏了，日志和监控对不上，排查问题会绕很大弯子。我的习惯是排查之前先date看一眼当前时间，如果不准就先用chronyc或ntpdate同步，不然花半天查一个不存在的"延迟"就亏了。
3.2 进程管理与系统负载：top、ps、free 的正确打开方式
top命令我一天要敲好几次，但它有个新手容易忽略的点：默认按CPU使用率排序。生产环境CPU飙高时，先看top输出里第一名的PID，然后ps -fp PID查看完整命令行，确认是什么程序。如果是Java应用，用top -Hp PID看线程级别的CPU占用，再拿到线程号转成十六进制，到线程栈里定位具体代码。完整的排查链路是：
# 第一步：看机器整体负载 top # 第二步：定位具体进程信息 ps -fp 12345 # 第三步：查看该进程下哪个线程吃CPU top -Hp 12345 # 第四步：把线程号转十六进制 printf "%x\n" 12345看到load average这三个数字时，很多新手会慌。其实这三个数分别代表1分钟、5分钟、15分钟的平均负载，要和CPU核数结合起来看。单核机器负载到1.0就已经满了，8核机器负载到8.0才算打满。判断瓶颈时，我习惯把5分钟和1分钟的数值对比：如果1分钟远高于15分钟，说明负载正在快速上升，大概率是即时流量或者定时任务造成的。
还有个容易踩的坑：负载高但CPU不高。这种情况多半是D状态（不可中断睡眠）的进程在等IO，比如磁盘慢、NFS挂载卡住。查看方法：
ps -eo state,pid,cmd | grep "^D" | grep -v grep如果一堆D状态进程，那就别纠结CPU了，去看磁盘IO和存储挂载是否正常。free -h查看内存时，真正有参考意义的是available这一列，它表示在不触发swap的情况下还可以分给程序多少内存，比看used靠谱得多。
kill是管理进程的最后手段，我建议"优雅优先"：kill -15先让进程自己清理退出；只有确认对方卡死无法响应，才用kill -9强制终止。线上乱用kill -9导致数据写一半、缓存没落盘的案例，我见过不止一次。
3.3 网络排查：从 ping、ss 到 curl 的完整链路
网络问题的排查链路通常是这样走的：先ping测连通性和延迟，通了你再测端口，端口通了你再看应用层协议。ping不通不代表服务不可用，可能是防火墙丢弃了ICMP包；ping通但不能访问服务，问题多半出在端口或应用层。
查看端口监听状态，新系统推荐ss而不是netstat，ss速度更快、信息更全。常用组合：
ss -lntp这个命令列出所有监听中的TCP端口及对应的进程名和PID，排查"8080端口被谁占了"就是ss -lntp | grep 8080。netstat -tulnp的作用类似，但较老的系统才会用到。
测试远端服务端口是否开放，telnet是最直接的：
telnet 192.168.1.100 8080如果端口通，会连接成功；如果超时或者Connection refused，说明端口没监听或中间被防火墙拦截了。比telnet更好用的还有nc -vz host port，能返回更清晰的状态信息。
应用层接口调试基本靠curl。我在排查接口返回、测试REST接口时，最常用的参数是-i（显示响应头）、-v（显示详细交互过程）、-X POST（指定请求方法）、-H（设置请求头）、-d（传请求体）。比如模拟一个POST请求看响应：
curl -i -X POST http://localhost:8080/api/login \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"123456"}'curl -w还可以输出请求耗时详情，之前排查接口慢的时候，靠它一眼看出是DNS解析慢还是连接建立慢还是响应慢，比一顿瞎猜高效得多。
3.4 磁盘与文件系统：df、du 与目录瘦身
磁盘满是最常见的"小故障"之一。df -h看整体使用率，du -sh看具体目录占用。当发现根分区满了，我一般按这个顺序排查：
# 顶层占空间 du -xh --max-depth=1 / | sort -rh | head # 如果 /var 占用大，继续深入 du -xh --max-depth=1 /var | sort -rh | head-x表示不跨文件系统，避免把/proc、/sys这类虚拟文件系统也算进去；--max-depth=1只显示一层目录，避免输出爆炸。这个两层钻取的方法，能很快定位到大文件目录，比如日志目录/var/log、临时目录/tmp、容器目录/var/lib/docker。
删除日志文件后，如果df还是显示100%，往往是有进程还在占用已删除的文件。可以用lsof | grep deleted找出这些进程，重启进程或服务后空间才会真正释放。这个坑我踩过一次：删了几G的日志文件，磁盘占用纹丝不动，后来才知道是Java进程还握着文件句柄，搞明白后真想拍自己一下。
du和ls -lh显示的文件大小不一致也经常有人问。原因是ls显示的是逻辑大小，du显示的是磁盘实际占用块大小，两者差距大通常意味着文件是稀疏文件或者有大量空洞，一般不用太在意。
4. 开发场景高频命令：vim、gdb 与容器操作
不是所有读者都做运维，但几乎所有开发岗都绕不开vim、调试工具和容器。这部分的命令，平时可能用不到，一旦用到就是救命级别的。
4.1 vim 必会操作：从"不知道怎么退出"到高效编辑
vim是每次Linux入门都会被提到的话题，很多新手在vim里卡住是因为它有两种模式。默认打开是普通模式，这时按键盘上的字不是输入，而是命令。要输入内容得先按i进入插入模式，写完后按Esc回普通模式。
我整理了一份自己常用的vim快捷键清单，不多，但覆盖了90%的使用场景：
i在光标前插入，a在光标后插入，o在下方新开一行插入Esc回到普通模式，:w保存，:q退出，:wq或:x保存退出，:q!强制不保存退出- 普通模式下
dd删除整行，yy复制整行，p粘贴 :set nu显示行号，:set nonu关闭行号；永久显示行号在~/.vimrc里写set nu- 上下左右可以用
h、j、k、l移动，小段移动够用 /关键词在文件中搜索，按n跳到下一处u撤销，Ctrl+r重做
我在工作中vim用得最多是快速修改配置文件：打开文件 →Shift+g跳最后一行 →o插入 → 修改 →Esc→:wq，全程不超过十秒。新手最常见的卡顿是开了vim后按了Ctrl+s，终端直接冻结，以为死机了。其实Ctrl+s是终端锁屏快捷键，按Ctrl+q解锁就好。
4.2 gdb 调试常用命令：崩了别慌，先看堆栈
如果写C/C++或者嵌入式代码，gdb是绕不开的工具。编译时一定要加-g选项保留调试信息，否则gdb里看不到源码和函数名，等于拿着一张没有标记的地图找路。
我调试时最常用的是下面这几个命令：
gdb ./app启动调试，如果要传参用gdb --args ./app --config=prodbreak 文件名:行号设置断点，比如break main.c:25run运行程序，start则是停在main函数入口（编译优化后可能定位不准，但一般够用）next单步执行不进入函数，step进入函数内部print 变量名查看变量值，比如print array[0]backtrace或bt打印函数调用栈——程序崩溃后，这是第一优先执行的命令info breakpoints列出断点，delete 断点号删除断点
程序崩溃后出现core dump文件，用gdb ./app core打开，执行bt就能看到崩溃时的调用栈。这里有个经验：如果栈显示是一个不认识的系统库函数，先把栈帧往前翻几层，多半能在自己的代码里找到问题。
gdb是交互式工具，不太适合写脚本化测试。如果要在崩溃时自动执行命令，可以用gdb -batch -ex "run" -ex "bt" ./app这种方式，适合让CI快速收集崩溃栈。
4.3 Docker 常用命令：容器操作与日志排查
容器化普及之后，同事们问我最多的Linux命令，有一半其实是Docker命令。这里挑几个高频操作讲一下，Docker本质是运行在Linux上的进程，所以很多排查逻辑还是依赖底层Linux命令。
# 查看所有容器（含已停止的） docker ps -a # 查看运行中容器的资源占用 docker stats # 看容器日志，tail模式 docker logs -f --tail=200 容器名 # 进入容器内交互执行命令 docker exec -it 容器名 /bin/bash # 从宿主机拷贝文件到容器 docker cp ./config.json 容器名:/etc/app/config.jsondocker logs是排查容器应用问题最常用的命令，-f可以实时跟踪输出。如果日志里有大量"无法连接数据库"这类报错，先用docker exec进入容器，在容器内部用ping和curl测试连通性。容器网络模式和宿主机不同，宿主机通不代表容器通。docker stats能看容器资源占用，如果某个容器CPU或内存长期打满，多半是应用有问题，而不是容器本身的问题。
很多Docker容器为了精简体积，默认没有装ps、vim、curl这些工具，进入容器后发现命令不存在的处境我经常遇到。我的习惯是优先用宿主机的命令排查容器的网络和资源，不得已要进容器时，再apt install或yum install临时工具。容器本身是临时环境，尽量别在里面装太多东西，保持镜像干净。
5. 面试高频Linux命令题：回答思路比命令本身更重要
Linux常用命令被面试官翻来覆去地问，不只是为了考察你记不记得命令，更是通过命令的使用逻辑看你的排查思路和问题定位能力。准备Linux面试题时，不能只背命令，要把完整的排查链路和"为什么这样做"讲清楚。
5.1 经典考题：CPU飙高，怎么排查
面试官问这道题，期望听到的不是"用top看一下"这一句话，而是完整思路。我的回答框架是：
首先用top看进程级别的CPU占用，找到吃CPU的PID，然后ps -fp PID确认是什么程序。如果是Java应用，用top -Hp PID找到具体线程，线程号转十六进制，再jstack PID导出线程栈，grep定位到出问题的线程。如果是PHP或Python应用，去看对应的慢日志和错误日志。如果是自己的写的程序，用strace -p PID可以追踪系统调用，看它在忙什么——虽然不能直接定位业务逻辑问题，但能排除文件读写、网络等待这些嫌疑。
这里有个加分项是提到vmstat或mpstat看CPU是用户态高还是内核态高、是否伴随着上下文切换飙升。还有对单核和多核的比较——单核CPU负载到1.0就是打满，8核要到8.0才算打满，这体现了对load average的理解。
5.2 经典考题：磁盘满了，怎么清理
这道题考的是排查思路和命令的熟练度。我会说：先用df -h确认哪个分区满了，再用du -xh --max-depth=1逐层找到占空间的目录。找到后看具体是什么——如果是日志目录，先确认还有没有进程占着文件句柄，用lsof | grep deleted找出来；如果没有进程占用，直接删或压缩归档。
回答时如果能补充"删了文件但空间没释放是因为进程持有句柄"这个坑，面试官会觉得你有真踩坑经验。另外还可以提到安全习惯：清理前先du -sh确认目标大小，rm前确认路径，备份文件用mv到临时区而不是直接删。这些细节比单纯报命令名有含金量得多。
5.3 经典考题：端口被占用、服务起不来
服务启动失败是工作中最常见的故障之一。排查8080端口的思路：先ss -lntp | grep 8080看端口是否被占用，被占了就ss -lntp拿到PID和进程名，决定kill还是改配置。如果端口没被占，看服务日志，用journalctl -u 服务名或tail -100 日志文件。
如果日志里出现权限拒绝，用ls -l检查文件归属，chown改所有者和chmod加权限。出现配置文件格式错误，用nginx -t或systemctl status 服务名的输出定位。这一串思路本质上是用命令做"排除法"，能流畅复述出来，面试官就知道你是真的处理过线上问题的人。
6. 我的实操心得：避坑清单与个人经验
最后这部分是我自己踩过坑之后整理的备忘，也算是一个"命令安全使用手册"，希望对你有用。
第一，命令执行前先想想后果。特别是在root权限下，一行rm -rf就能毁掉几个月的成果。我的习惯是：删除前先ls确认目录内容，rm前用echo $路径确认变量非空，能用mv到/tmp就先用mv，确认没问题了再清。改了配置先nginx -t或systemctl config check验证，再执行重载。这些习惯看起来烦琐，但能保证你在深夜操作的时候不手抖。
第二，管道命令要小心"假成功"。默认情况下，一个管道命令的退出码取决于最后一个命令的退出码。比如grep "error" 日志 | head -5，即使前面grep没匹配到任何内容，整个命令也会返回0。在脚本里判断执行结果时，要用set -o pipefail，否则会误判。一次同事写脚本反复出问题找不到原因，最后就是管道退出码惹的祸。
第三，别依赖记忆，用man和history。我记不住的参数，从来不硬背，直接用man 命令名查手册。觉得手册太长的时候，先用whatis 命令名看一句话描述，再用apropos 关键词搜索相关命令。日常操作时，history记录了我敲过的每条命令，想知道"上一次解决这个问题用的什么参数"，直接在终端输入history | grep 关键词就能翻出来。这套"查询链"不是不记命令，而是把记忆负担变成了检索能力，长期用下来反而对命令的语义理解更深了。
第四，命令的输出要做"人话翻译"。top输出的那一堆数字，free显示的buffer和cache，df里inodes的概念，如果没有解释很容易误判。我的经验是先理解每个指标的含义，再判断系统是否真的有问题。比如free -h里used很高不代表内存不够，因为Linux会把空闲内存用作缓存，只要available充足，系统就是健康的。
写到这里，我把这个系列第六篇的内容基本倒完了。Linux常用命令没有太多捷径，就是多用、多踩坑、多复盘。但我可以负责任地说，一旦你按照场景把这套命令体系建立起来，日常工作和面试题都不太会难住你。最后如果你正处于入门阶段，建议从今天开始给自己定个目标：每天在终端里把当天用过的命令和场景记到一个markdown文件里，三个月后你会惊讶于自己的积累。
