Linux命令实战：不是背出来的，而是用出来的排查方法论

在带新人和做分享的时候，我经常被问到类似的问题："有没有一份最全的 Linux 命令大全？""我背了几天命令，到新服务器上还是不会用。"说实话，Linux 命令这玩意儿，真不是靠背出来的。你背得再熟，换个环境、换套权限、换个发行版，原来能跑通的命令照样能给你整出各种幺蛾子。真正有用的"命令大全"，不是给你列一个几千条命令的清单，而是把命令背后那套逻辑讲明白，让你知道什么场景该用什么命令、出问题去哪查。这篇内容我按实际工作里最常用的场景来组织，从基础语法到文件操作、系统排查、网络调试、软件管理、权限控制，再到把多个命令组合成一条高效的"命令流"，尽量把我这些年踩过的坑也一并写进去。

1. 命令学习的第一课：先懂语法，再谈记忆

1.1 一条命令的"通用骨架"

不管什么命令，基本都可以抽象成这样一个骨架：

code复制命令名 [选项] [参数]

命令名决定你要干什么，选项决定你怎么干，参数决定你作用在谁身上。比如 ls -l /etc，ls 是命令名，-l 是选项（long format，长格式输出，显示更多属性），/etc 是参数，也就是我们要看的目录。

选项又分短选项和长选项。短选项是一个横杠加一个字母，长选项是两个横杠加单词。例如：

• ls -a 和 ls --all 效果一样，都表示显示隐藏文件
• ls -a -l 可以合写成 ls -al，这是短选项的合并写法

为什么有的命令帮助是 -h，有的却是 --help？这跟命令出身、遵循的规范有关，GNU 类命令通常两者都支持，BSD 或嵌入式精简版可能只支持其中一种。遇到不确定的情况，先敲看一下输出，比去搜索引擎猜要快得多。

理解了骨架，你会发现大部分命令的用法是相通的。你学会了一个命令的安装、启动、状态检查方式，其他命令也能用同样的思路去摸清。这个"迁移能力"，比记住一百条命令更有价值。

1.2 查命令的正确姿势：man、info、whatis 到底该用谁

很多新人查命令只会用搜索引擎，其实系统自带的手册已经足够强大了。man 是最常用的在线手册工具，但它的坑在于输出很长，而且不同内容分布在不同的章节里：

当你知道 passwd 可能是用户命令（改密码）也可能是文件格式（/etc/passwd）时，就不会困惑为什么 man passwd 出来的不是改密码的说明。想指定章节，用 man 5 passwd 这样写。想按关键词搜索手册，用 man -k passwd 或者等价的 apropos passwd，它会列出所有手册里相关的条目，这个用法比你想关键词更精准。whatis passwd 则给出每一条的一句话概括。

info 是 GNU 手册的另一套体系，内容更深更细，但日常排查问题我一般先看 man，再看 --help，只有写系统级程序文档时才去翻 info。总之一句话：先 type 看命令，再 man 查手册，最后 --help 看示例，这是绝大多数排查问题的第一步。

1.3 终端环境差异：同一个命令，不同 shell 下结果不同

我在带人时发现，很多人把 Bash 和 Linux 划等号，结果在别的 shell 环境下就蒙了。常见 shell 有 Bash、Zsh、Fish、Dash 等，它们对某些语法支持不太一样。比如 [[ ]] 条件测试在 Dash 的 /bin/sh 环境里可能报错，而你的登录环境默认是 Bash 就没事。所以当你写脚本时，#!/bin/bash 和 #!/bin/sh 背后的解释器可能不同，执行效果也可能不同。

还有一个容易踩的坑：部分命令在嵌入式 Linux 里被精简掉了。比如完整版系统里 ps aux 能看所有进程，但某些嵌入式系统用的是 busybox 版本，ps 只能看当前终端的进程，选项也不一样。这解释了为什么热词里有人搜"xilinx ise linux 启动""嵌入式linux项目"时会遇到连 ls 输出颜色都不同的情况。不是你不会用，是环境做了裁剪。

2. 文件与目录操作：最常用的命令里藏着最深的坑

2.1 删除文件夹前，先想清楚 rm -rf 的边界问题

"linux删除文件夹命令"是高频搜索词了，答案其实就是 rm -r。-r 表示递归，删除目录下的所有子文件和子目录；-f 表示强制，不提示直接删。但我必须强调：rm -rf 是 Linux 上最危险的一条命令，没有之一。

先说最常见的误删场景。假设你的脚本里写了：

code复制rm -rf $dir/*

如果 $dir 因为某种原因没被赋值，这条命令就变成了 rm -rf /*，它会以当前用户权限去递归强制删除根目录下所有文件，大概率直接导致系统崩溃。安全习惯是：删除变量路径前先判断变量是否为空，或者写成更稳妥的写法：

code复制[ -n "$dir" ] && rm -rf "${dir:?}/"*

${dir:?} 的语法会让变量为空时报错退出，从根上避免灾难。

再说 rm -rf $dir/ 和 rm -rf $dir 的区别。多一个斜杠，在绝对路径下差别不大，但在变量拼接时容易让人看走眼。我个人的习惯是删除前先 ls -ld $dir 看一眼，确认路径正确再删。真有重要数据的机器，我会把 rm 做成别名指向 trash-cli 的命令，删除后还有个后悔药。

2.2 find、grep、ls 的实用组合

ls 是所有人都会用的命令，但很多人只用 ls 而不加参数。日常工作中 ls -lah 是能救命的：-l 看权限和大小，-a 显示隐藏文件，事后 -h 格式化文件大小，读起来不费眼。

要在大目录里找文件，别靠 ls 一层层翻，直接上 find。最常用的组合：

code复制find /var/log -type f -name "*.log" -mtime +7

解释一下：-type f 只看普通文件，-name "*.log" 按文件名匹配，-mtime +7 找到 7 天前修改过的文件。配合 -exec 可以直接处理结果：

code复制find /tmp -type f -name "*.tmp" -mtime +7 -exec rm {} \;

{} 是 find 对每个结果的占位，\; 表示一条命令的结束。这种写法比先 find 再复制粘贴要省事得多，也不会因为文件多、空格多而出错。

grep 是另一个高频命令。通常配合 -r 进行目录递归搜索，-n 显示行号，-i 忽略大小写，-v 反向匹配。排查日志时我常用这种姿势：

code复制grep -rn "ERROR" /var/log/app/ | head -20

别在日志目录里直接 cat 文件，日志一大就容易刷屏。先用 grep 把想要的过滤出来，再用 head 限制行数，这是基本素养。

2.3 grep、sed、awk 三剑客：文本处理不是为了炫技

这三个命令为什么叫"三剑客"？它们解决的是三类核心问题：查找、替换、提取。

• grep 查找：已经讲过了，核心是过滤。
• sed 替换：最常用的是 sed -i 's/old/new/g' file。-i 表示在原地修改，s 是替换命令，g 是全局替换。注意 -i 会直接改文件，建议先不加 -i 跑一遍看输出，确认无误后再加。
• awk 提取：awk '{print $2}' 的意思是按空白分隔，输出第二列。-F 可以指定分隔符，比如处理 /etc/passwd：

code复制awk -F: '{print $1}' /etc/passwd

这里 -F: 表示按冒号分隔，输出第一列，也就是用户名列表。这三个命令组合起来能完成大量文本处理任务，比如从日志里提取某个时间段的 IP、从配置文件中批量修改参数等。

我想强调一点：文本处理不是目的，拿到结果去分析才是目的。很多人学完 awk 就拿来炫技，写出一行谁都看不懂的代码，这反而违背了这个命令的初衷。能用清晰的管道组合实现功能，就别硬凑"一行流"。

2.4 history：你不是记不住命令，是不会用历史

"history命令详解"一直是热门搜索，我猜原因是大家知道自己该用历史记录，但不知道怎么高效用。"linux 命令记不住"这个问题的正解，就是让 shell 帮你记。

history 可以列出当前用户输入过的历史命令。常用的几个技巧：

• !$ 代表上一条命令的最后一个参数
• !! 代表上一条命令
• !123 代表执行历史中编号 123 的那条命令
• Ctrl + R 进入反向搜索，输入关键词直接搜历史

还有几个能让历史更好用的配置。默认 Bash 只记几百条，而且不显示时间，你可以这样改：

code复制export HISTSIZE=10000
export HISTTIMEFORMAT="%F %T "

HISTSIZE 控制内存里的记录数，HISTTIMEFORMAT 让 history 输出带时间戳，方便回溯"我当时到底执行了什么命令"。这些配置写到 ~/.bashrc 里，重开终端就生效。

3. 系统状态排查一条龙：CPU、内存、进程、磁盘

3.1 ps 和 top：看懂进程到底在干什么

排查系统问题时，最常问的一句就是"现在机器上到底在跑什么"。回答这个问题，ps 和 top 是两块基石。

ps aux 是我最常用的形式。输出里需要重点关注的是 PID、CPU、MEM、STAT 这几列。CPU 和 MEM 好理解，STAT 是进程状态，常见的有：

看到 D 状态的进程多，大概率磁盘有瓶颈；看到 Z 状态一直存在，要查父进程为什么没有正确回收子进程。这是排查方向上的线索。

如果想实时看，用 top。进入界面后，按 P 按 CPU 排序，按 M 按内存排序，按 1 展示每个 CPU 核心的负载。第一行的 load average 有三个值（1 分钟、5 分钟、15 分钟），参考时要注意 CPU 核数。四核机器 load 4 左右算满负荷，双核机器 load 2 就算很高了，不能一概而论。

3.2 free、df、du、iostat：内存和磁盘的问题定位

free -h 输出里有个经典疑问：明明还有大量 cache 内存，为什么 free 列却很小？这其实不是内存不足，而是 Linux 把空闲内存用作缓存，提升文件读写性能。真正要看的是 available 这一列，它表示还能拿来给新程序用的内存量。

磁盘层面，df -h 是看文件系统整体用量，du -sh * 是看当前目录下每个子目录占多大。排查"磁盘满了"的问题时，我会先 df -h 找哪个分区满了，再在那个分区用 du -sh 逐层往下找大目录，比盲猜快得多。

iostat 是看磁盘 IO 的工具。重点看 %util 列，接近 100% 说明磁盘已经很忙，可能导致前面说的 D 状态进程增多。这个工具如果没装，包管理命令装一下即可，属于 sysstat 软件包。

3.3 systemctl 和 journalctl：管理服务的现代化姿势

CentOS 7 之后，主流发行版都切换到 systemd，服务管理基本都通过 systemctl 完成：

code复制systemctl start nginx
systemctl enable nginx
systemctl status nginx

enable 表示开机自启，这个特别重要。很多人配置完服务当时能跑，重启机器后服务不见了，就是因为少了一步 enable。查服务日志用 journalctl，比如：

code复制journalctl -u nginx --since "10 minutes ago"

这能拉出 nginx 服务最近 10 分钟的日志。加 -f 参数可以像 tail -f 一样实时跟踪，排查启动失败时非常常用。如果 journalctl 拿不到日志，那就要看服务的日志文件具体写到哪，通常可以去 /var/log/ 下找。

3.4 典型场景：redis 启动命令为什么这么容易搞不定

热搜词里"redis启动命令"频繁出现，其实就是 systemd、可执行文件、客户端 ping 三者的配合问题。常规步骤：

code复制systemctl start redis
redis-cli ping

如果返回 PONG，说明通了。如果卡在连接，要看 redis.conf 里绑定的 IP 和端口，默认只绑 127.0.0.1，外部机器连不上是正常的。如果你还在用老式的 redis-server redis.conf 方式启动，启动后终端会被占用，要加 --daemonize yes 或者用 nohup 放到后台。我把这几种启动方式的差异记住，基本就能覆盖大多数场景了。

4. 网络排查实战：从 ping 到 iptables 的完整链路

4.1 时代的替身：ip 命令 vs ifconfig

如果你在网上搜教程，大概率还会看到很多 ifconfig 的例子。但新一代系统里，ifconfig 可能没装，还要单独装 net-tools。现在官方主推的是 ip 命令。

• ip addr：查看所有网卡的 IP 地址
• ip route：查看路由表
• ip link：查看网卡链路层状态

我以前排查"上不了网"时，第一步就是 ip addr 看网卡有没有拿到 IP，再 ip route 看默认网关是否正确。而 ifconfig 显示的内容相对有限，很多信息还要再用 route -n 补充。建议新学的朋友直接用 ip，这是趋势。

4.2 端口通不通：telnet 的替代方案

"telnet命令怎么用"也是常搜的问题。以前我们用 telnet ip port 测试某个端口是否开放。但现在的问题是，很多新系统默认不装 telnet 客户端；而且 telnet 本身是明文协议，有安全风险，不建议随便装。

替代方案有好几个：

code复制nc -zv 192.168.1.10 80

-z 表示只扫描端口不发送数据，-v 输出详细信息。更"原生"的写法是用 Bash 自带的 /dev/tcp：

code复制timeout 3 bash -c "echo > /dev/tcp/192.168.1.10/80" && echo open

如果端口通，会输出 open；不通，命令会超时退出。这个技巧在机器上没有 nc、没有 telnet 时非常管用，因为 /dev/tcp 是 Bash 内置的特性，不需要额外装东西。

4.3 nslookup 与 dig：DNS 解析问题排查

"nslookup命令结果详解"在热搜里有一定热度。简单说，nslookup 输出的核心是：

• Server 和 Address：这是当前用的 DNS 服务器地址
• Name：查询的域名
• Address：最终解析出来的 IP

如果出现多个 Address，特别是有的 IPv6 有的 IPv4，别急着认为是解析错误。可以用 nslookup <域名> <指定DNS服务器> 指定别的 DNS 再看看结果是否一致。需要更详细的信息（比如 TTL、权威服务器），用 dig 会更清楚。

4.4 iptables 命令详解：防火墙到底拦了什么

iptables 是很多人的心头痛，其实抓住几条核心规律就不难。

先理解“表”和“链”的概念。最常用的表是 filter 表，用于过滤数据包；它有几个内置链，我们平时主要在 INPUT（入方向）、OUTPUT（出方向）、FORWARD（转发）上做规则。

查看规则：

code复制iptables -L -n -v

-L 列出规则，-n 不做反向解析直接显示 IP，-v 显示计数。添加一个允许某端口入站的规则：

code复制iptables -A INPUT -p tcp --dport 22 -j ACCEPT

-A 表示追加到链尾，-p tcp 指定协议，--dport 22 指定目的端口，-j ACCEPT 表示动作是放行。删除规则把 -A 换成 -D 即可。

我在实际排错中见过好多次"服务明明在监听，但外面怎么都连不上"的情况，十有八九是防火墙默认策略是 DROP，但又忘了加放行规则。排查思路很简单：先看监听，ss -tlnp 确认端口在监听；再 iptables -L -n 看规则放不放行；最后再确认云平台安全组是否放行。这三层任一层面拦截都会导致连接失败。

这里必须提醒一句：iptables -F 是清空所有规则，在远程服务器上执行可能会导致你当前的 SSH 连接被拒。我建议在需要清空规则时，先输出当前规则备份，再谨慎操作，最好操作前确认有带外管理通道能救你。

5. 软件包管理与容器命令：发行版差异全解析

5.1 apt、yum、dnf、pacman：四大包管理器的核心逻辑

不同发行版的包管理命令看着五花八门，但底层逻辑几乎是一样的：更新元数据、安装软件、卸载软件、升级系统。区别主要在命令名和辅助参数上。

不要试图死记硬背，把左侧"功能"记熟，再映射到不同系统即可。遇到一个新发行版，先看它属于 Debian 系还是 RHEL 系，命令基本就八九不离十了。

5.2 包文件层面的操作：rpm 和 dpkg

上面说的管理器通常解决"从仓库装"的场景。如果拿到一个 .rpm 文件或 .deb 文件，就得用底层工具直接操作。

• rpm -ivh package.rpm：安装一个 rpm 包
• rpm -qa：列出所有已安装的 rpm 包
• dpkg -i package.deb：安装一个 deb 包
• dpkg -l：列出所有已安装的 deb 包

为什么有时用 apt install 装不上，但 rpm -ivh 能装上？因为前者会检查依赖，后者默认不做依赖解析，只做安装。实际生产里我尽量用包管理器装，只有离线环境才用 rpm -ivh 或 dpkg -i，装完还得自己确认缺少哪些依赖，非常折腾。

5.3 containerd 与 docker：容器的命令配套

热词里出现 "containerd命令"，说明现在很多人在容器环境里做运维。Containerd 是容器运行时，比 Docker 更底层，很多 Kubernetes 节点上只装了 containerd，没有 docker 命令。

containerd 的命令行工具是 ctr，高频操作：

code复制ctr images pull docker.io/library/nginx:latest
ctr containers create docker.io/library/nginx:latest nginx
ctr tasks start nginx

但说实话，ctr 的命令体验没有 docker 友好。日常调试如果装了 crictl，可以按 CRI 风格操作：

code复制crictl pull nginx:latest
crictl ps
crictl logs <容器ID>

如果你已经在用 docker，核心命令就是这些：

code复制docker pull nginx
docker run -d --name web -p 80:80 nginx
docker ps
docker exec -it web bash
docker logs -f web
docker stop web && docker rm web

很多人搞不清 run 和 start 的区别：run 是创建并启动一个新容器；start 是启动一个已经存在、但当前停止的容器。初次创建用 run，以后启动用 start。

5.4 典型场景：Linux 系统安装 Python 的依赖坑

"linux系统安装python" 也是高频搜索。有些系统自带的 Python 版本太低，项目又要新版，就需要源码编译安装。但源码安装最烦的是依赖：缺 zlib、缺 libffi、缺 openssl-devel，编译到一半报错又得回头补包。

以 CentOS 系为例，编译 Python 前先装这些库：

code复制yum install -y gcc openssl-devel bzip2-devel libffi-devel zlib-devel readline-devel sqlite-devel

在 Ubuntu/Debian 系则是：

code复制apt install -y build-essential libssl-dev zlib1g-dev libffi-dev libreadline-dev libsqlite3-dev

然后才是标准的解压、configure、make、make install 流程。我建议能用包管理器装 Python 就别编译，比如 apt install python3，版本一般够用。真要装新版，用 pyenv 这类版本管理工具也比手动编译好维护。

6. 权限管理：sudo、su、chmod 之间的那些事

6.1 文件的权限模型：r、w、x 到底意味着什么

Linux 的权限模型可以用一条命令看清：

code复制ls -l /etc/passwd
-rw-r--r--. 1 root root 1892 1月  18 10:30 /etc/passwd

从第二个字符开始，每三个字符一组，分别是 owner（文件所有者）、group（所属组）、other（其他人）的权限。r=4，w=2，x=1，所以：

• rw- 表示 4+2=6，可读可写
• r-- 表示 4，只读
• rwx 表示 4+2+1=7，可读可写可执行

修改权限用 chmod，比如 chmod 755 script.sh 表示 owner 有全部权限，组和其他人有读和执行权。修改所属用户和组用 chown、chgrp。目录的 x 权限表示能否进入该目录，这跟文件的 x 权限含义不一样。很多权限相关的怪问题，十有八九是把这两个概念搞混了。

6.2 sudo 与 su：切换权限的正确打开方式

su 不带用户名时默认切换到 root，但它要求你输入目标用户的密码。一旦 root 密码弄丢，麻烦就大了。sudo 则不同，它是用当前用户的密码来获得临时提权，权限由 /etc/sudoers 控制，可以精细化到某个用户能执行哪些命令。

所以推荐日常使用 sudo，尽量不要开放 root 直接登录。修改 sudoers 用 visudo 命令，它会做语法检查，避免因为写错 sudoers 导致所有提权失效。看到很多新人偷偷改 /etc/sudoers 导致整个系统无法提权的案例，我总要多说一句：visudo 的语法检查就是为你兜底的。

6.3 提权概念的授权理解

热搜里有"linux提权"，这里要说明白：在正规运维和开发授权范围内，提权通常是指利用 sudo、su、setuid 位等机制，让普通用户临时获得执行管理任务的权限。setuid 是权限模型里一个特殊位，在 ls -l 里表现为 owner 的 x 位置出现 s。比如 /usr/bin/passwd 就带 setuid 位，普通用户执行它时能以 root 权限修改自己的密码，这是系统设计的安全机制。

理解这个机制有助于排查权限相关的问题，也能帮助你更谨慎地配置文件和脚本的权限，避免给脚本随意加 setuid。超出授权范围的提权攻击手法，不属于正常运维工作讨论的内容，我也不建议碰。

7. 把命令组合起来：并行执行与高效命令流

7.1 分号、&&、||、管道：连接命令的四种逻辑

命令之间的组合符号，看似简单，实则排错时经常踩坑：

• cmd1; cmd2：无论 cmd1 是否成功，cmd2 都会执行
• cmd1 && cmd2：只有 cmd1 成功，才执行 cmd2
• cmd1 || cmd2：只有 cmd1 失败，才执行 cmd2
• cmd1 | cmd2：把 cmd1 的标准输出作为 cmd2 的标准输入

实际使用中，&& 是最常见的。比如：

code复制apt update && apt upgrade -y

只有更新元数据成功，才继续升级，避免在一个已经出错的环境里继续瞎装。管道则常用于文本处理链路，比如：

code复制cat access.log | grep "404" | awk '{print $1}' | sort | uniq -c

这是一条很经典的命令流：从访问日志里筛出 404 状态码的 IP，去重统计出现次数。管道链上的每个命令都只负责一件事，组合起来就能解决一个相对复杂的需求。

7.2 xargs 与并行执行

"并行执行linux命令"是热搜词，大多数人刚接触时会想到用后台符 &，比如：

code复制command1 &
command2 &
wait

& 把命令放到后台，wait 等所有后台任务结束。这只适合命令比较独立的场景。如果要对一批文件执行同一个命令，并且想并行，用 xargs 更合适。

code复制find /data -type f -name "*.log" -print0 | xargs -0 -P 4 -I {} gzip {}

解释一下：-P 4 表示同时跑 4 个进程，-I {} 表示用 {} 占位，每条结果都会作为参数传给 gzip 命令。这里的 -print0 和 -0 是为了处理文件名中的空格，配合操作在文件名不规范时特别有用。

7.3 我常用的几个生产命令组合

就着这些基础操作，分享几个我在生产环境里高频使用的组合，都是经过反复验证的。

第一条，大规模替换文件里的配置项：

code复制find ./conf -type f -name "*.conf" -exec sed -i 's/192.168.1.10/192.168.1.20/g' {} \;

第二条，批量查看当前目录下哪些目录占空间最多：

code复制du -sh */ | sort -hr

第三条，后台运行一个脚本并把日志写到文件：

code复制nohup ./deploy.sh > deploy.log 2>&1 &

> deploy.log 把标准输出重定向到日志，2>&1 把标准错误也合并到同一日志，& 放后台。

这些组合看起来简单，但我见过不少同事遇到需求时只会手工操作，完全不知道用 find、xargs、管道把这些动作自动化。学会组合之后，效率完全是两种状态。

我自己的体会是，Linux 命令的学习曲线确实陡，但它不是靠背出来的，是靠"遇到问题->找到命令->理解参数->动手验证"这个循环滚出来的。你可以先把我上面说的这些命令用熟，再按自己的实际场景慢慢扩展，慢慢你就会发现，新命令学起来越来越快，因为所谓的"命令大全"其实就是一套你已经建立起来的知识脉络。这套脉络建立起来之后，换哪个发行版、哪个精简环境，你都能很快接住手头的活儿。