我见过太多人下载了一份《Linux命令大全》收藏了十几种“常用命令总结”真到线上服务出问题的时候还是只会敲个ls和ps -ef | grep java。说句实话Linux命令从来不是背出来的它是按场景“使”出来的。这篇东西我不想再罗列什么大全而是想从自己日常处理问题的顺序出发讲清楚命令是怎么组织、怎么组合、怎么在真实环境里派上用场的。无论你是刚接触服务器的新手还是已经被各种面试题折磨过的求职者按这个思路重新过一遍命令你会发现自己之前很多地方都在低效重复。1. 命令不是背出来的先解决学习思路的问题1.1 我见过最多的高效错觉很多人学命令的第一步是去找一份“Linux常用命令大全”从ls到tar从awk到find挨个背参数。结果背了三天键盘敲得飞快一到真实场景还是懵top那一屏数据到底看哪个数netstat和ss有什么区别为什么ping不通但网页能打开这不是记性差而是把命令当成了“字典词条”去背。实际上命令是工具工具的价值在于“用在哪、干什么”。我后来统计过自己日常运维和开发中真正反复调用的命令长期活跃的其实不到50个而且它们高度集中在几个明确场景里。把这些场景单独拎出来练熟远比盲目追求“大全”有效得多。比如我自己的高频命令清单大概长这样场景常用命令系统信息uname、lscpu、free、df、du、uptime文件操作ls、cd、cp、mv、rm、find、tar、ln文本处理cat、grep、sed、awk、sort、uniq、wc网络排查ping、telnet、nc、ss、netstat、tcpdump、curl进程与服务ps、top、kill、systemctl、journalctl权限账户chmod、chown、sudo、useradd、passwd软件包apt、yum、dnf、rpm这张表不是让大家背下来而是给一个“命令地图”的概念你不需要记住每条命令的每个参数只需要知道遇到哪类问题去哪个工具包里找答案。把地图建起来学习才有了锚点。1.2 按“动作”而不是按“名字”去学举个例子ls不是一条命令而是一类动作查看目录内容、查看文件权限、查看隐藏文件、按时间排序查看。当你说“我需要看这个目录下最近修改过的文件”对应的动作就是ls -lt当你说“我想知道为什么这个目录这么大”对应的动作是du -sh。带着动作去学命令才跟实际问题挂上钩。同理grep不是背“行匹配工具”这个定义而是“我要在一堆日志里把报错行挑出来”“我要在配置文件里忽略注释和空行找到有效配置”。一旦你习惯了用“我要做什么”去反推“该敲什么命令”你会发现自己对参数的记忆时间比死背长得多。这套思路贯穿整篇文章后面每一章其实都是“场景驱动”的具体演示。2. 命令的基本骨架看懂五个通用组成任何命令都不再是黑盒2.1 命令、选项、参数、路径的组合套路Linux命令的通用形态是命令 选项 参数 路径。很多人被各种命令的花式写法搞晕其实底层结构非常稳。选项通常负责“改行为”参数和路径负责“指对象”。我举一个最典型的例子ls -l /etc/hostsls是命令本身决定动作类型-l是选项告诉命令用“长列表格式”输出/etc/hosts是参数/路径告诉命令“作用在哪个对象上”。选项还分两种风格。像ls -l这种短选项用单横线加一个字符适合日常手敲像ls --human-readable这种长选项用双横线加完整单词适合写脚本时让对方能看懂。有些命令为了兼容还支持“短选项合并”比如ls -lh就是-l和-h合在一起写意思是“长格式显示并且把文件大小转成人类易读的K/M/G”。这里有一个新手最容易忽略的点选项和参数的顺序不是固定的但路径尽量放在最后。绝大多数命令遵循“命令 选项 参数 路径”的书写顺序但部分命令比如find和tar允许把路径放在前面。遇到不确定的建议先跑一下命令 --help看它Usage行怎么写。我见过不少同事因为把目标路径写到选项前面导致命令行为完全失控比如find -name *.log /var/log和find /var/log -name *.log执行结果完全不同。还有一类命令比如vim它本身就是个“交互式程序”。你执行vim file.txt后命令并不会立刻结束而是进入一个等待你操作的环境。这种命令不能用“选项决定一切”的思路去套它的核心用法反而是快捷键:q退出、:wq保存退出、/关键词搜索。所以我一直觉得vim 不用强求记一堆高级操作先把“打开、编辑、保存、退出、撤销、查找”这六个动作练顺手就足够应付绝大多数临时改配置的场景了。2.2 管道与重定向命令组合的底层逻辑命令能不能发挥威力不取决于你记住多少条而取决于你懂不懂“组合”。Linux的哲学是“每个命令只做一件事把它做好”然后把小工具串起来完成复杂任务。串起来的核心就是管道符|和重定向符、、。管道的意思很直白把左边命令的输出直接作为右边命令的输入。我举一个日常工作里的场景你想看看当前系统里有哪些Java进程。ps -ef | grep javaps -ef负责把系统所有进程列出来grep java负责从输出里过滤出包含“java”的行。没有管道的话你得把ps -ef的结果先保存到文件再用grep去读文件效率低得多。管道就是命令界的“传送带”让数据在多个程序之间流动起来。重定向则负责“把输出送到哪里去”。表示覆盖写入表示追加写入。新手最容易踩的坑是把当成“无所谓方向”的符号结果把配置文件内容清空了。我记得有人执行echo hello nginx.conf想测试写入一瞬间把整个Nginx配置覆盖成一行字恢复都没法恢复。这是我在实际工作里见过最贵的“手误”之一。正确的组合思路是先想清楚“数据从哪来、要到哪去”再用|把处理工具连起来用或把结果落到文件里。比如systemctl status nginx 21 | tee /tmp/nginx_status.log21表示把标准错误也并入标准输出避免只看到一部分报错tee在把结果写给文件的同时还能继续打印到屏幕上。这种组合在排查线上问题时几乎天天用。理解了管道和重定向你再去看别人的命令脚本就会发现它们不过是“处理步骤按顺序排列”而已没有任何魔法。3. 网络排查实战为什么我优先用 ss 而不是 netstattelnet 为什么还活着3.1 ping 通了不代表端口通了一个典型的排查误区网络排查是Linux命令最见功力的地方也是最容易误判的地方。搜索量最高的ping命令实际上被寄予了过多期望。ping走的是ICMP协议很多云服务器的安全组和本机防火墙默认会屏蔽ICMP于是出现“ping不通但业务完全正常”的反直觉结果反过来ping通了也仅仅代表“主机活着、网络路由通”不代表“目标端口能接受连接”。我举个真实案例。有一次同事反馈应用服务连不上数据库他先ping 数据库IP等了半天没回应直接断定“数据库挂了”。我登录数据库服务器一看CPU、内存、连接数全都正常MySQL明明在监听3306端口。问题出在哪数据库服务器的安全组把ICMP禁掉了但TCP连接是放行的。用telnet IP 3306一测端口秒通。所以说ping适合看“主机在不在”要看“端口通不通”必须用TCP层面的工具。3.2 端口连通性测试telnet、nc 与 /dev/tcp 的三选一说到测端口今天很多教程推荐ncnetcat但telnet IP 端口依然是我在实际中最常用的原因特别简单它几乎所有Linux发行版都自带没有安装门槛而且连上之后你还能手动发送内容比如对HTTP端口发一个请求头看返回判断服务类型。telnet 192.168.1.10 80如果端口打开屏幕会提示连接成功通常显示“Connected to”甚至进入一个可以输内容的黑窗口如果端口关闭或不响应命令通常会卡住然后报“Connection refused”或超时。注意telnet在这里只是当“端口探测器”用和真正的运维管理协议没关系所以别看到telnet就觉得是不安全的旧技术。nc比telnet更适合写脚本自动化比如nc -vz 目标IP 端口会直接返回“succeeded”或“refused”参数中的-z表示“只扫描不发送数据”。还有一个非常轻量的做法用Bash内建的网络重定向。echo /dev/tcp/192.168.1.10/80 echo port open这段脚本式的写法不需要额外安装任何工具适合在容器镜像里快速判断端口状态。我通常会按场景选临时手动排查用telnet写脚本用nc -zv容器里没有额外工具时用/dev/tcp。3.3 一套可复制的排查顺序真实网络问题很少只有一个原因我习惯按“从粗到细”的顺序走一遍。第一步ping 目标IP确认基础连通性和延迟第二步ss -lntp或netstat -lntp看本机端口监听状态确认服务到底有没有起来第三步telnet 或 nc测远端端口最后如果还不对再用tcpdump抓包看数据包是否到达、是否被重置。为什么现在更推荐ss而不是netstat因为ss直接从内核socket信息读取数据结果的时效性和可读性都更好尤其在端口数量多、连接量大时netstat容易拖慢系统。很多新装系统里netstat甚至需要额外安装net-tools包而ss属于iproute2工具集默认就有。所以我日常几乎不用netstat。ss -lntp这个命令组合的含义是只看监听状态的TCP端口-l-t不解析服务名直接用端口号显示-n把对应进程信息也打出来-p。它是回答“服务起来没有、监听在哪个地址、哪个进程在监听”最直接的一行命令。4. 文本处理的正确姿势grep定位、sed批改、awk统计的配合节奏4.1 grep 先用好这几个参数就够了Linux日志和配置文件全是文本文本处理三剑客grep、sed、awk的熟练度直接决定了你处理问题的效率。先讲grep。它最基本的功能是“按行过滤”但很多人只会grep 关键词 file遇到复杂需求就无从下手。我实际用下来四个参数最值得记grep -E ERROR|Exception app.log # 用扩展正则匹配多种报错关键词 grep -v ^# nginx.conf # 反向匹配排除注释行 grep -A 5 StackOverflow app.log # 匹配到的行和后面5行一起显示 grep -c timeout app.log # 统计匹配行数-E是正则表达式的入口没有它|会被当成普通字符而不是“或”的意思-v用来做过滤器比如你想看配置里真正生效的行最好先排除掉注释和空行-A和-B则是看上下文遇到异常堆栈时只看报错行通常不知道错在哪得连后面的调用栈一起看。这四条组合起来已经能覆盖大部分日志定位场景。4.2 sed 的要领定址、动作、原地修改搜索量同样很高的sed命令本质是“流编辑器”它按行读取内容对每一行执行你指定的操作。我最早用sed只会干一件事替换字符串。sed -i s/old-text/new-text/g config.conf这个命令的结构值得拆开看s是替换动作g表示这一行里所有匹配的地方都替换而不是只替换第一个-i表示“直接修改原文件”。很多教程对-i一笔带过但我想强调一个保命习惯重要文件做sed -i前先不加-i跑一遍确认输出内容符合预期再决定要不要真的写入。比如sed s/foo/bar/g nginx.conf只是把结果打印到屏幕上文件本身不动这时候你完全可以检查输出对不对。我现在处理生产配置几乎一定会先试跑再落盘。sed常用的不只是替换还有按行范围处理。比如你想看/etc/passwd的第10到20行sed -n 10,20p /etc/passwd-n的意思是“不打印每一行的默认输出”p才是“打印我指定的行”。这两个参数经常一起出现少了-n整个文件会被重复打印出来输出乱成一团。理解本章开头的“骨架”思路后你会发现sed的行为本质也是“定址 动作”先选行再决定对这些行做什么干什么都顺手。4.3 awk 入门从日志里统计Top IPawk的学习曲线比grep和sed陡但实际用到的核心概念就两个按列分割和按条件处理。它默认按空白字符把每一行拆成多个“字段”$1是第一列$2是第二列以此类推。以一个经典需求为例从Nginx访问日志里统计出现次数最多的前10个IP。日志格式一般是192.168.1.5 - - [10/Oct/2024:13:55:36 0800] GET / HTTP/1.1 200 1234第一列就是客户端IP。用一行awk加sort加uniq就能完成awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这段命令的意图很清晰awk先抽出第一列IPsort把相同IP聚到一起uniq -c统计每项重复次数并输出计数sort -rn按计数从大到小排序最后head -10只留前10行。这就是“管道组合”的经典演示也是面试里经常被问到的场景。我第一次跑这个命令时犯过一个低级错误忘了加sort直接用uniq -c结果出来一大堆计数为1的行。因为uniq默认只合并“相邻且相同”的行不先排序相同IP分散在文件各处就统计不出来。这个经验让我养成了“先排序再uniq”的肌肉记忆。awk还能做求和、平均值等简单计算比如统计日志里所有请求的返回字节数总和awk {sum $10} END {print sum} access.logEND块表示处理完所有行之后再执行非常适合汇总类需求。文本处理三剑客的正确用法从来不是互斥的而是grep先粗筛sed改格式awk做列操作和统计配合管道形成一条处理流水线。5. 进程、服务与容器从 ps 到 systemctl再到 docker 与 containerd5.1 ps 和 top 怎么配合使用排查性能问题和“某进程怎么找不到了”核心是ps和top。ps是快照执行的那一秒看到什么就是什么top是持续的动态视图定期刷新。我习惯用ps找进程ID和启动路径用top观察CPU、内存随时间的变化趋势。ps各种参数风格很乱我建议直接记住一套通用写法ps -ef这个组合在几乎所有Linux发行版上都可用会输出每个进程的UID、PID、PPID、CPU使用率、启动命令等信息。想按进程名快速找ID用管道接grep或直接pgrep -f。比如要找到Nginx的master进程和管理进程pgrep -af nginxtop看起来眼花缭乱但真正要关注的列不多第一行的load average负载均衡值%CPU和%MEM两列以及进程STATE。如果某个进程CPU持续接近100%结合ps拿到的PID再用strace -p PID追踪系统调用基本就能定位问题。top里还有个快捷键值得记按P按CPU排序按M按内存排序。很多面试题“怎么查看系统负载”“怎么查进程占用CPU”其实考察的就是这两条命令的熟悉程度。5.2 systemctl现代服务管理的中心传统service命令和/etc/init.d/脚本体系在主流发行版里基本已经让位给systemd。systemctl现在是服务管理的中心入口它管理的不只是服务的启动/停止还包括开机自启、依赖关系、资源限制。systemctl status nginx # 查看服务状态包括是否运行、如何启动、最近日志 systemctl start nginx # 启动服务 systemctl enable nginx # 设置开机自启 systemctl daemon-reload # 修改了服务配置文件后重载配置很多人只知道start和stop却经常漏掉daemon-reload。我遇到过不止一次同事改了/etc/systemd/system/xxx.service文件直接systemctl restart xxx发现改动没生效然后怀疑配置文件写错。其实systemd不会在每次重启服务时自动读取修改后的unit文件必须先用daemon-reload通知它“配置变了”。这是一条非常典型、非常容易踩的坑。日志查看也建议一并掌握journalctl -u nginx --since 1 hour agojournalctl配合-u过滤指定服务的日志查启动失败的原因时比翻/var/log下的零散日志高效得多。每次看到“服务起不来系统里面却没有任何输出”的求助帖我几乎都会推荐先用journalctl -u 服务名看一眼八成都能找到真正的报错。5.3 容器场景docker 与 containerd哪里容易犯迷糊现在的Linux环境里容器技术绕不开。很多人把docker系列命令背得很熟但对下层运行时containerd的概念模模糊糊。简单梳理一下docker是面向用户的管理工具它把镜像构建、容器运行、网络配置集成在一起containerd是更底层的容器运行时负责真正去拉起和管理容器docker背后其实也是通过containerd去执行容器相关的生命周期操作。日常使用中docker ps看运行中的容器docker logs -f 容器名跟日志docker exec -it 容器名 bash进入容器调试。这几个命令是使用频率最高的也是排查“容器启动了但业务不通”的第一步。比如我通常会先确认容器有没有退出docker ps -a-a参数非常关键因为出问题的容器往往已经退出了不带-a只显示正在运行的容器你根本看不到它。再配合docker logs看容器内部输出大部分问题都能定位到启动参数、环境变量或卷挂载上。containerd的命令行工具ctr平时不怎么直接碰但有两类场景会遇到一是把镜像从docker导入到containerd命名空间二是排查Kubernetes节点上的镜像缓存。ctr和docker的命令风格很像常用的是ctr images list、ctr run但要注意ctr操作的是命名空间隔离的默认往往需要指定-n k8s.io才能看到K8s相关的镜像。第一次用它时我因为没有指定命名空间看到空列表差点以为镜像丢了。6. 权限与账户管理sudo 的设计逻辑和几个容易踩的配置坑6.1 权限模型rwx 和数字法Linux文件权限模型本质是“三组权限 x 三个对象”。三个对象是所有者owner、所属组group、其他人others每组可以授予读r、写w、执行x三种权限。用ls -l看到的-rw-r--r--就是这9个权限位的简写。数字法chmod 644 file是所有人都会用但很多人没搞懂数字怎么来的。规则是r4、w2、x1把同一组权限的值相加得到该组的数字位。所以644就是所有者可读写426组和其他人只读4。这种设计最大的好处是精简9个权限位压缩成3个数字写脚本时非常方便。比如给脚本加可执行权限chmod 755 deploy.sh755表示所有者可读写执行其他人可读可执行。新手通常会问“为什么不是777”因为普通运维场景里不能让别人随便改你的脚本。少一个写权限就少一大类误操作和篡改风险。6.2 sudo 不是 su为什么这个问题很关键很多教程会把sudo和su放在一起讲但两者理念完全不同。su是“切换用户”切到root后后续所有命令都以root身份执行相当于把整个终端的权限级别都抬高了sudo则是“用特定用户的身份执行单条命令”当前shell身份不变。我极其不建议日常使用su -切到root因为一旦切过去很容易忘记自己正在以最高权限操作。改错一个配置、删错一个目录成本极高。sudo的设计逻辑是“最小权限 留痕”只有真正需要提权的命令才加sudo而且日志会记录谁在什么时间执行了什么命令。不建议用的反面则是完全不理解sudo的默认行为它是“失败的静默者”。比如sudo cat /etc/shadow如果你当前用户不在sudoers里或者不在被授权的用户组中命令会直接报错“不在sudoers文件中”。很多人这时候第一反应是“我是不是密码错了”其实问题出在授权配置而不是密码。正确做法是用root身份或通过有权限的账号编辑/etc/sudoers把用户加入wheel组或用visudo加入规则。记住修改sudoers一定要用visudo而不是直接vim因为visudo自带语法检查写错了不会让你保存坏文件。有一次我手动改sudoers写漏一行导致所有用户都无法执行sudo救援时只能通过pkexec临时提权去修复折腾了半小时。6.3 账户安全细节过期提醒和弱口令风险账户管理里还有一个搜索热度很高的小需求让系统在密码快要过期时提醒用户。默认Linux密码策略可能不会天天提醒可以通过修改/etc/login.defs里的PASS_MAX_DAYS、PASS_WARN_AGE来调整。比如设置PASS_MAX_DAYS 90 PASS_WARN_AGE 14意思是密码最长使用90天到期前14天开始警告。改完后可以用chage -l 用户名查看当前策略是否生效。这个需求和“服务器密码过期后SSH登录被拒”的经历经常连着出现很多人没意识到自己的密码策略已经生效直到远程登录失败才追查。所以我建议是在新账号创建时就明确设置策略而不是等出问题再补救。另外哪怕有sudo授权也不代表可以随意开通root登录。我一直坚持“禁止root直接SSH登录改为普通用户sudo”的习惯。具体做法是确认你有一个可正常sudo的账号后再编辑/etc/ssh/sshd_config设置PermitRootLogin no然后重启sshd。这个过程最需要注意的是顺序——先确保备用提权通道可用再关闭root直连否则万一sudo配置写错可能连机器都进不去。7. 让命令真正长在身上man、history、脚本化与面试应对7.1 用 type 和 man 建立准确的信息来源学命令最好的老师不是搜索引擎而是系统自带的帮助文档。man 命令名能打开详细的手册页但很多新手一看满屏英文就放弃了。我的建议是不用全部读完重点看两个区域SYNOPSIS告诉你命令的基本用法格式OPTIONS列出所有可选参数。比如man ls时先扫一眼格式再找自己需要的参数具体解释。还有一个搜索热度不高但极其实用的命令type。它能告诉你“某个命令到底是什么类型”。比如type cd type ls type docker输出结果可能是“shell内建命令”“alias别名”“外部命令位于某个路径”。这个区别非常关键cd是shell内建你用which cd根本查不到路径ls在某些发行版里可能是alias lsls --colorauto的别名你不了解这点换到另一个没有这个别名的环境发现ls没有颜色还会以为是系统坏了。先type搞清楚命令的“出身”后续排查和脚本化都不容易走偏。7.2 让 history 和 alias 成为你的外脑人的记忆不可靠但终端的history很可靠。我有个使用习惯执行完一条复杂的、以后可能复用命令先history | grep 关键词把它找回来如果它确实需要反复使用就把它写成alias放在~/.bashrc里。比如我经常用的一条命令是查看服务启动日志里有没有报错堆栈history | grep journalctl找到原命令后我通常直接改成alias了alias jljournalctl -u nginx --since 10 minutes ago -falias相当于给长命令起一个短名写进~/.bashrc后每次新开终端自动生效。它不只是“省打字”更是把高频操作沉淀成你自己的命令语言。我今天的工作流里有大量这种自建别名gl看git logdd看docker psff用find按文件名找文件。这些命令组合的熟练度其实就是个人效率的分水岭。7.3 面试题考的不仅是命令更是排查思路Linux面试题搜索量常年很高我从面试官视角说两句。很多所谓“面试真题”比如“如何查找占用8080端口的进程”“如何查看系统负载”“如何统计access.log里的状态码数量”表面上是考命令实际上考的是“你有没有一个清晰的排查链路”。以“查找占用8080端口的进程”为例思路应该是一条线走下来先用ss -lntp | grep 8080找到端口对应的PID再用ps -fp PID或ps -ef | grep PID查看进程详情必要时ls -l /proc/PID/cwd看它的工作目录。这个过程中命令只是工具真正被考察的是“你知不知道怎么从现象找到进程、再从进程找到归属应用”。所以准备Linux面试与其把几十页命令大全背完不如把几条最典型的排查链路自己手敲一边网络不通怎么查、CPU飙高怎么查、磁盘空间不足怎么查、服务起不来怎么查。把链路跑通面试和实际工作都能应付。最后再分享一个我个人的习惯遇到新命令不要立刻收藏而是自己手动在测试机器上“玩”一遍用type看类型用--help看参数再随便找个测试文件试试效果。这个“试错”过程本身就比任何教程都印象深刻。Linux命令是工具工具就得在手里用起来才谈得上真正掌握。