Linux常用命令分类速查表：从文件操作到系统排查的实战指南

一开始被同事追问“Linux常用命令到底该怎么记”的时候我总习惯回一句“多敲几次就记住了”。但其实这话挺糊弄人的真正的速成方法不是背几百个命令而是按使用场景把高频命令分类先建立目录感再往目录里填细节。这篇Linux常用命令分类速查表就是按这个思路整理的覆盖文件操作、用户权限、系统服务、磁盘网络、软件安装、开发工具、进程日志这些日常跑不掉的场景适合运维、后端开发、嵌入式方向的同学也适合刚装完Linux虚拟机还处于“只会ls和cd”阶段的新手。我一个做运维的朋友说过一句很有道理的话命令不需要全会够用就行但高频场景里的那几十条值得刻进肌肉记忆。下面这些内容基本就是我平时在工作里反复使用、踩过坑之后沉淀下来的一套速查体系每类命令里我也顺手标注了容易翻车的细节尽量让你少走弯路。1. 文件与目录操作最高频但最容易翻车的几个细节文件操作是Linux里最基础也最常用的一类命令可越常用越容易出事故。先别急着炫技把下面这几个命令的危险边界搞清楚比记住一百个快捷键值钱。1.1 rm、cp、mv删除和复制的安全替代方案先说rm。很多人刚开始用Linux就学会了rm -rf但真正上过生产环境之后我对这个命令的态度只剩谨慎、谨慎、再谨慎。你可能会觉得夸张但我确实见过有人把rm -rf /usr/local/写成rm -rf /usr多敲了空格和路径前缀也见过在脚本里用变量拼接路径结果变量为空直接变成rm -rf / 的跨年事故。所以第一条经验是任何rm操作之前先echo一遍路径确认无误再执行。更推荐的替代方案是不要直接删尽量先mv到临时目录。比如想删除一个叫old-project的目录可以先执行mv old-project /tmp/trash_$(date %F)等观察几天没问题再彻底清理。这个习惯在操作数据库目录、代码仓库、Nginx站点目录时尤其实用。如果你实在喜欢rm至少别把根目录和home目录放一起操作每次删之前用df、ls确认自己当前在哪个目录。cp和mv也有容易被忽略的点。cp复制目录必须加-r这个大家都知道但很少有人注意目标路径是否以斜杠结尾的区别。cp -r a b/表示把a放进b目录里cp -r a b表示把a复制成b如果b不存在则重命名。mv跨文件系统时本质上先复制再删除大目录会明显卡顿等不及以为卡死就强制中断反而更容易留下半成品目录。另外我建议你养成用rsync代替cp -r做重要数据备份的习惯特别是目录里有大量小文件时rsync可以断点续传还能用--delete做增量同步脚本里也更好控制。一个稳妥的备份命令rsync -av --progress --delete /data/www/ /backup/www_$(date %F)/1.2 find、grep与管道组合别再一条条翻文件了很多新手找文件只会用ls加Tab补全目录稍微一深就抓瞎。find可以说是Linux里检索能力最强的命令之一值得花点时间记几个常用组合。find /etc -name *.conf # 按文件名找 find /var/log -mtime -7 # 找最近7天修改过的文件 find / -size 1G # 找大于1G的文件 find . -type d -name node_modules -prune # 排除某些目录 find /tmp -name *.log -exec ls -lh {} \;-exec是很多人不敢碰的参数其实理解起来很简单{}表示find找到的每一个文件;表示命令结束。上面这条命令做的就是“找到所有.log文件然后对每个文件执行ls -lh”。权限动作谨慎一些可以用-ok替代-exec执行前会逐个询问。grep用来配合作业时最常用的是-r递归搜索和-l只显示文件名。想象一下这个场景线上某台机器的Nginx配置里代理地址错了你需要在/etc/nginx下一堆.conf里找到哪个文件引用了旧地址直接一条命令定位grep -rn 192.168.1.100 /etc/nginx/配合管道和xargs基本上能做到一步到位。比如把搜索结果里的文件直接交给vim打开逐个确认grep -rl error_code_505 /app/logs/ | head -20 | xargs vim提示find和grep这两个工具是管道操作的黄金搭档遇到复杂检索需求优先想它们而不是搜GUI工具。不过find在软链接目录上偶尔会绕圈建议加-maxdepth限制深度既提速又避免意外遍历到系统目录。2. 用户权限与系统管理新建用户、sudo边界和时间同步一网打尽跨过文件操作之后第二个容易让人迷糊的区域是用户与权限管理。这类命令平时用得不算特别频繁但一旦涉及部署项目、配置服务每一条都是硬需求。2.1 新建用户与sudo配置提权的边界必须清楚很多云服务器到手默认是root用户直接登录这个习惯很不好。我自己被安全扫描邮件教育过之后再也不敢开着root的密码登录了。正确做法是先新建一个日常操作的用户把sudo权限配好然后改用密钥登录。新建用户的标准流程直接看这段命令useradd deploy # 创建用户 passwd deploy # 设置密码 usermod -aG wheel deploy # 加入wheel组CentOS系 usermod -aG sudo deploy # Ubuntu系的sudo组如果你希望新用户的家目录和默认shell一起配好可以加参数useradd -m -s /bin/bash deploy。-m表示创建home目录-s指定登录shell。很多人创建完用户忘记加-m结果用户登录后连家目录都没有各种工具配置写到一半报permission denied。sudo的配置在/etc/sudoers里官方建议不要直接改这个文件用visudo命令编辑它自带语法检查防止你改坏了之后谁也提不了权。我只提醒一个原则给用户的sudo权限越窄越好。比如某条命令不需要root就能跑就千万别写进sudoers业务用户一般也不需要NOPASSWD: ALL这种规则除非你确认该环境是隔离测试机。还有个小细节很多云镜像默认禁用了root远程登录这对安全是好事。但有些人图省事直接改/etc/ssh/sshd_config里的PermitRootLogin为yes改完一定要执行systemctl reload sshd而不是restartreload不中断已有连接万一配置写错了还能补救restart就直接掉线了。2.2 系统时间同步与systemctl服务管理服务器时间不对是个隐蔽又致命的问题。日志时间错乱、定时任务乱执行、数据库主从同步报错很多怪问题的根源都是时间漂移。我经常用date先看当前时间再用timedatectl确认时区。date # 查看当前时间 timedatectl status # 看时区和NTP状态 timedatectl set-timezone Asia/Shanghai # 修改时区 systemctl status chronyd # 检查NTP客户端状态 chronyc sources # 查看时间源同步情况如果你的系统装的是chrony基本不需要手动ntpdate了配置文件在/etc/chrony.conf里。CentOS 7之后多数是chrony替代了ntp这套Ubuntu 20.04也是。时间同步这块我踩过的坑是云服务器明明配了NTP却一直同步失败后来发现是内网DNS把时间服务器域名解析到了一个不可达的地址直接在chrony.conf里改成国内时间源IP才解决。systemctl这套服务管理命令是现在Linux系统管理绕不开的核心systemctl start nginx systemctl enable --now nginx # 开机自启并立刻启动 systemctl restart nginx systemctl reload nginx # 平滑重载配置不断连接 systemctl status nginx # 查看运行状态和最近日志 journalctl -u nginx -f # 跟随查看服务日志一句话经验凡是Nginx、Docker这类对外服务的配置变更优先用reload而不是restartreload是平滑重载用户几乎无感知restart会断开当前连接在业务高峰期操作就是事故。3. 磁盘与网络排查运维现场真正救命的一套组合拳如果前面还只是日常操作这一节的内容属于真正的排障硬通货。无论是云服务器还是物理机磁盘满和网络异常几乎占运维故障的一半以上。3.1 磁盘空间与文件系统这一步先搞清楚再动手每次接到“服务突然不可用”的告警我的排查流程里第一条固定指令就是df -h。磁盘满了以后很多服务不会给你报一个优雅的“磁盘已满”错误而是各种奇怪的响应超时、写入失败、临时文件无法创建。df -h # 查看各分区使用率 df -i # 查看inode使用率 du -sh * # 当前目录下各文件/目录的大小汇总 du -h --max-depth1 # 只看一层避免刷屏inode这个参数必须有姓名。很多人只盯磁盘空间忘了inode也会满。inode是文件系统用来记录文件元信息的索引节点如果某个目录下因为程序bug生成了几十万个空文件df -h看着还剩几十G但服务就是创建不了新文件。这时候df -i一看就知道再用find /data -type f | wc -l排查具体哪里爆了。lsblk和blkid用来查看块设备和文件系统类型在挂载新硬盘、做数据盘扩容时是主力。比如阿里云扩容数据盘后系统层面必须执行growpart和resize2fs或xfs_growfs才能真正用到新增空间这部分逻辑各云厂商文档都有但原理是一样的先看partition表变了没再看文件系统是否已扩展到新边界。一个容易被忽略但非常典型的故障是“文件被删除但空间没释放”。场景通常是应用还在运行某个大日志文件被rm了但进程仍然持有文件句柄df显示磁盘还是满的。排查手段是lsoflsof L1 | grep deleted找到仍持有已删除文件句柄的进程后重启或让应用重新打开日志文件空间才会真正释放。这个坑我在线上踩过好几次每次都能靠这一条快速定位。3.2 网络连通性与端口排查从ping到tcpdump一条链路捋清网络问题最挫败的就是“看起来没断但服务就是访问不了”。我的排查顺序永远是自下而上先看链路通不通再看端口起没起最后抓包看协议层有没有奇怪内容。ip addr # 查看网卡和IP ip route # 查看路由表确认默认网关 ping -c 4 目标地址 # 基础连通性 ss -tlnp # 列出所有监听端口及其对应进程很多老文章还在推荐netstat -tlnp实际上现在的ss命令又轻又快输出格式也更清晰信息基本一致。端口没监听、端口被防火墙挡了、端口监听在127.0.0.1而不是0.0.0.0这三种情况分别对应三种完全不同的错误用ss一眼就能区分。应用层连通我习惯用curl -v它能打印完整的握手过程和响应头curl -v http://127.0.0.1:8080/healthz-v之后你能清楚看到DNS解析是否正常、TCP连接有没有建立、TLS握手卡在哪个环节、HTTP状态码和响应时间。排查内外网访问差异时我在服务器上执行curl -I http://内网域名再在家用电脑上执行同样的域名两边输出一对比问题基本定位了一半。如果怀疑网络层有奇怪的丢包或重传上tcpdump抓包不要犹豫tcpdump -i eth0 port 8080 -c 20 -n-n参数一定要加不然它会把所有IP反向解析成域名又慢又容易被DNS干扰。抓包结果里看到大量TCP Retransmission那基本就是链路质量问题跟应用层代码没关系这时候再翻代码就是浪费时间。4. 软件安装与开发环境从GCC编译到Git、SQL、GDB的速记命令再熟练最终还是要落到“把项目跑起来”这件事上。软件安装、编译调试、代码管理和数据库操作是开发环节最绕不开的四板斧。4.1 包管理与源码安装安装Python/GCC的前后细节apt和yum/dnf两套体系用起来差别不大记住一组常用结构就能举一反三apt update # 刷新软件源索引 apt install -y gcc g make # 安装开发工具链 apt search python3 # 搜索软件包 apt remove --purge nginx # 卸载并删除配置CentOS系则把apt也换成yum或dnfdnf更推荐dnf install -y gcc。安装GCC这件事看起来简单其实很值得多提一句GCC版本太老会导致新项目编译失败比如某些C17特性在GCC 7里支持不完整。如果系统源自带的GCC太老用Software Collections或直接源码编译新版GCC都行。源码编译的套路高度雷同背下来一条流程所有开源软件都适用wget 源码包地址 tar -xzf gcc-13.2.0.tar.gz cd gcc-13.2.0 ./configure --prefix/usr/local/gcc-13 make -j$(nproc) make installmake -j后面的参数意思是并行编译使用的CPU核心数nproc命令自动获取当前CPU逻辑核心数能把编译时间压缩一大截。不过版本切换用update-alternatives更优雅比如在gcc 11和gcc 13之间切换两条命令搞定update-alternatives --install /usr/bin/gcc gcc /usr/local/gcc-13/bin/gcc 130 update-alternatives --config gcc安装Python也是同一条路径。比系统自带的Python3更省心的做法是源码编译指定版本然后软链接到/usr/local/bin/python3.x。务必注意不要动系统自带的/usr/bin/python3很多系统工具依赖它你强行替换版本容易把apt这类依赖Python3.6的工具搞坏。我见过太多人在这上面翻车最后只能重装系统。4.2 Git、MySQL、GDB三件套开发调试场景的高频命令Git命令太杂但日常用到的高频组合也就那么十几个。最实用的两个场景一个是关联远程仓库另一个是时间线回滚。git init git remote add origin gitgithub.com:user/repo.git git add . git commit -m feat: 提交说明 git push -u origin main git branch feature/login # 创建分支 git checkout -b dev # 切到新分支 git stash # 暂存未提交的改动 git log --oneline -10 # 看最近10条提交 git diff --cached # 查看已暂存但未提交的改动我特别建议重度使用git stash。写了一半的代码突然要去修线上bugstash一下切分支改完再切回来git stash pop比commit一个半成品再接reset干净得多。MySQL常用命令很多但DBA日常也就围绕几个核心动作转mysql -h 127.0.0.1 -P 3306 -u root -p SHOW DATABASES; USE dbname; SHOW TABLES; SELECT * FROM table WHERE id 1 LIMIT 10; CREATE USER app% IDENTIFIED BY 强密码; GRANT SELECT,INSERT,UPDATE,DELETE ON dbname.* TO app%; FLUSH PRIVILEGES;备份和恢复那两条建议直接写成脚本模板mysqldump -u root -p dbname backup_$(date %F).sql mysql -u root -p dbname backup_$(date %F).sql生产环境备份一定要加--single-transaction否则InnoDB表备份期间的数据一致性会很脆弱。GDB调试是嵌入式Linux和C/C研发的标配工具。初学者主要掌握这几个就够应付大多数段错误问题gdb ./your_program break main # 在main函数下断点 run # 开始运行 next # 单步跳过当前行 step # 进入函数内部 print varname # 打印变量值 backtrace # 查看调用栈段错误必备 info registers # 查看寄存器 continue # 继续执行遇到崩溃第一件事永远是backtrace而不是盯着代码发呆。它会把崩溃时的调用链完整拉出来几十层的函数调用一目了然省去大量猜测时间。5. 进程、性能与日志从现象到根因的完整排查链路最后一类也是最体现功力的一类当你面对一台表现异常的服务器时怎么在几分钟内判断它是负载过高、内存不足、进程失控还是日志爆满。5.1 进程管理与系统负载top、ps、free还是strace进程管理的核心是先分清楚“看一眼就知道”和“需要深入分析”两种场景。ps aux # 查看所有进程快照 ps -ef | grep java # 按名字过滤进程 top # 实时查看CPU/内存占用 free -h # 查看物理内存与swap pgrep -f 完整命令行片段 # 按命令行搜PID pkill -f 进程名 # 按命令行杀进程top进入界面后按P键按CPU排序按M键按内存排序这两个快捷键比任何参数都实用。如果top显示CPU使用率1234%那是多核累加值不代表机器有问题要看load average走势。load average三个数值分别对应1分钟、5分钟、15分钟的平均负载如果1分钟远高于15分钟说明系统负载正在快速上升是及时介入的信号。定位进程卡死、缓慢这类问题时strace是一把手术刀。它跟踪进程的系统调用某个进程一直处于不可中断睡眠态执行下面命令看它到底卡在哪个系统调用上strace -p PID -f -c-c参数是汇总统计跑几秒CtrlC退出后你能看到这个进程往哪个文件描述符上猛读数据还是在等待某个锁。之前我用这个方法定位过一个Tomcat假死问题发现它卡在读取一个无响应的NFS挂载点上跟JVM堆内存调优没有半点关系。5.2 日志与真实故障案例从tail -f到journalctl的逐层抽丝剥茧日志是故障排查的终点站也是起点站。大多数故障的根因线索都藏在日志里问题是你知不知道去哪找、怎么筛。几种最常见日志的路径/var/log/messages # 系统整体日志CentOS /var/log/syslog # 系统整体日志Ubuntu /var/log/nginx/access.log error.log /var/log/mysql/error.log查看日志最常用的三条tail -f app.log # 实时跟踪新增日志 tail -n 200 app.log # 看最后200行 grep -i error app.log | tail -n 50 # 过滤错误关键字假如某个接口突然开始大量5xx手里没有监控平台第一反应就是打开错误日志尾行看stack trace里把调用链走到哪个服务。顺序很重要先看错误日志的具体异常类型再根据时间点反查access log里的请求参数最后用curl模拟复现一次。journalctl是systemd时代管理服务日志的统一入口很多细节值得掌握journalctl -u nginx -f # 跟随某个服务日志 journalctl -u nginx --since 1 hour ago # 最近一小时 journalctl -u mysql --until 2024-01-01 00:00:00 journalctl -p err --since 2 hours ago # 只看最近2小时错误级别以上的日志这里分享一个真实故障案例有个服务每天凌晨3点准时崩溃。第一次排查时所有人都盯着应用日志发现崩溃前一条日志都没有直接是进程消失于是怀疑OOM。free -h确实看到内存余量很低但进一步分析coredump文件确认是某个后台任务一次性申请了超量内存触发内核OOM Killer把进程杀了。整个链路是这样的先用systemctl status发现进程异常退出再用journalctl -k查看内核日志看到oom-kill记录最后用free -h和dmesg确认内存压力来源。所以我的结论是遇到进程被无声杀掉的场景先查systemctl和journalctl -k不要拿应用日志瞎猜。还有一类日志相关的坑是logrotate导致的“日志文件丢失”。应用打开的日志文件被logrotate改名后应用还在往旧文件描述符里写结果磁盘悄悄变满。解决办法是修改应用的日志打开方式或者调logrotate的copytruncate参数这一条也是面试里高频考察的知识点。然后把排查经验浓缩成一句话先看磁盘再看内存再看进程最后看日志永远不要跳过第一层就直接下结论。真正的故障排查高手不是记忆力更强而是排查顺序更科学、每个层级会用最合适的命令。这套速查体系不是让你一次全部背下来而是在真实场景里用一次、忘一次、再查一次用多了这些东西自然就变成你自己的工具箱了。我平时有个习惯会在自己的笔记里维护一份精简的“个人速查本”只记录工作中真实用过的命令和踩过的坑格式大概就是本篇这种分类结构比任何网上的大而全手册都好用。毕竟再全的命令大全也没有你亲手跑过一遍的命令靠谱。