我先讲个很多新手都会问的问题Linux 命令这么多几百上千条到底怎么记才不头大我的答案不是“背”而是“分类”。把命令按照使用场景拆成几块每块记住它的核心逻辑剩下的边用边查这才是正经路子。我自己带过不少新人也算过烂不少坑最后沉淀下来的就是一份按场景划分的 Linux 常用命令速查表。这篇就把它完整写出来配合每个块的实战心得你照着用就行。先说这份内容到底能解决什么问题不管你是刚接触 Linux 的准运维、写代码但经常要在服务器上排查问题的开发、还是准备面试的大学生这份分类速查表都能帮你快速定位命令。它不追求把所有命令列全而是把最高频、最容易踩坑、最能在关键时刻救命的那部分拿出来按“文件、文本、权限、进程、网络、存储、开发工具、系统管理”这条主线铺开。你可以把它当工具书用也可以当复习提纲用。1. 先想清楚命令为什么不按字母背而是按场景分类1.1 理解 Linux“一切皆文件”的设计哲学Linux 和 Windows 最大的差别不是有没有图形界面而是底层逻辑。Windows 把磁盘分成 C 盘、D 盘操作系统、软件、数据各占一摊Linux 则是把所有资源——硬盘、键盘、网络、进程、配置全部抽象成文件。你操作文件用的是一套命令操作硬件用的还是那套命令只是路径不同而已。理解这点之后很多命令就不用死记了。比如你改网络配置实际上是在编辑/etc/sysconfig/network-scripts/ifcfg-eth0类似的文本文件你看 CPU 信息cat /proc/cpuinfo你看内核日志dmesg本质也是读文件。所以我在整理速查表时第一栏永远是文件操作因为它是整个系统的基础。1.2 我给速查表定的五条主线我整理表格的时候不是按字母 a-z 排而是按一个运维或开发人员的操作顺序排先看有什么文件目录再改内容文本编辑再调属性权限用户再看跑没跑进程服务最后收尾找问题日志网络。这个顺序对应着你解决一次线上问题的完整过程。举个例子你接到一个告警说服务挂了。第一反应是什么先ls看下目录结构、确认部署路径对不对再tail看日志、确认报错原因ps看进程是不是还活着ss看端口有没有监听df看磁盘是不是满了。这五条主线一套下来80% 的问题都能定位。所以不要东一榔头西一棒子地学命令按场景学、按问题路径学效率最高。2. 高频命令分类拆解从文件操作到文本处理2.1 文件与目录操作这是所有命令的地基这一组命令我默认每个人都要形成肌肉记忆ls、cd、pwd、cp、mv、rm、mkdir、touch、find。很多新手会轻视这组但恰恰是它们最容易翻车。几个值得注意的细节ls -l看到的文件权限、属主、大小、时间是判断文件状态的第一手信息。ls -lhtr按时间倒序日志轮转时非常好用。rm -rf一定要警惕。我在生产环境见到过太多人因为写错了路径把整个应用目录删光。我的习惯是删除前先mv到一个/tmp/垃圾箱目录观察一天没问题再删。这个习惯帮我挡过好几次大事故。find命令不是只用来搜文件名的。find . -name *.log -mtime 7 -delete可以清理 7 天前的日志find / -perm -4000可以找出所有 setuid 文件排查安全风险也靠它。配合-exec还能批量处理。2.2 文本处理四件套grep、sed、awk、cut这是整个速查表的精华区。不懂这四件套你只能算“会用 Linux”懂了才算“会玩 Linux”。grep的目标是从一堆文本里过滤出关键行。最常用的不只是grep 关键字 文件而是grep -r 关键字 目录递归搜索整个目录以及grep -v排除、grep -E用正则。排查日志时grep ERROR app.log | head -50能快速看到最近的报错。sed是做替换和编辑的。最经典的用法是sed -i s/old/new/g file把文件里的所有 old 替换成 new。注意-i是直接改原文件加上它会覆盖不加就只是输出到屏幕不会修改文件。新手经常忘了-i替换完发现文件没变还以为命令错了。awk是列处理神器。默认按空格分列awk {print $1, $3}取第一和第三列。进阶用法awk -F: {print $1} /etc/passwd按冒号分隔把系统所有用户名列出来。配合条件过滤awk $3 100 {print $1}能完成简单统计。cut更轻量适合按分隔符切列。比如cut -d: -f1 /etc/passwd和上面 awk 效果一样但语法更简洁。我自己的习惯是简单切列用 cut要做条件判断和统计用 awk。2.3 权限与用户chmod、chown、useradd 的正确姿势权限命令是 Linux 安全的闸门。chmod 755 file、chmod x script.sh大家都会但有几个容易忽略的点。chown除了改属主还能改属组chown root:root file。更实用的是用-R递归改目录比如部署应用后需要把整个目录改成 nginx 用户chown -R nginx:nginx /data/www。这里有个实际问题改了属主却发现服务还是没权限读很可能是目录中间层的权限没放开比如/data本身的权限是 700下面子目录设置得再好也不行。用户管理方面useradd建用户后要立刻passwd 用户名设置密码。生产环境更推荐useradd -s /bin/bash -m 用户名明确指定 shell 和建家目录。顺带提醒一句不要把 sudo 权限配得太宽松。visudo里给用户配ALL(ALL) NOPASSWD: ALL那条等于把服务器钥匙挂门口我见过很多服务器就是这么被掏空的。给最小化权限、用sudo审计日志这才稳。我写命令时有一条“三板斧”原则先把权限、属主、路径打印清楚再动手操作。比如执行chmod前先ls -l看当前状态执行删除前先find看目标内容。磨刀不误砍柴工至少能防止一半以上的人为失误。3. 运维场景实战日志、网络、磁盘一套带走3.1 日志排查tail、grep、less 的黄金组合线上故障排查日志是唯一可信的现场。我的组合拳是tail -f看实时输出grep过滤关键字less翻长文件。tail -f /var/log/app.log实时跟日志服务启动时这行命令能让你看到报错是不是打印在最后几行。tail -n 500 app.log | grep ERROR看最近 500 行里所有报错比直接打开几百 MB 的日志文件省太多事。遇到超大日志文件别用 vim 打开直接用less。它不会一次性把整个文件读进内存几十 GB 的文件也能翻得动。在 less 里按/关键字搜索按n连续匹配这是查长日志的利器。还有一个做法值得推荐把多台机器的日志聚合到一个 MySQL 或 Elasticsearch 里用 SQL 或 Kibana 查效率远胜手割 ssh。但如果手头没有集中式平台掌握好 tail、grep、less 的组合单机排查完全够用。3.2 网络诊断curl、ping、ss、traceroute 从外到内网络问题是最容易让人抓狂的。我习惯按“从外到内”的顺序排查先确认能不能出去ping 外网再确认服务有没有监听ss再确认端口通不通nc、telnet最后用 curl 实际请求一次看返回码。ping 目标IP测连通性但很多云厂商会禁 ICMPping 不通不一定是网络断。ss -lntp列出所有正在监听的端口及对应进程比老命令netstat输出更清晰。ss -ant看所有 TCP 连接状态排查大量 TIME_WAIT 时就靠它。curl -I http://域名看 HTTP 响应头返回 200、301、502 分别代表什么状态这是判断 web 应用好不好用的第一手证据。traceroute IP追踪路由路径能看出是哪一跳出了问题。实际上很多网络问题出现在中间运营商或防火墙traceroute 可以帮你快速定位到具体节点。一条实战经验当应用提示连接超时先别急着重启服务。先在服务器本机curl一次通了说明服务没问题是外部链路再用另外一台同网段服务器测通了说明是客户端到你服务器这一段的问题。一层一层剥比两眼一抹黑强太多。3.3 磁盘存储df、du 和挂载 NAS 的实战磁盘满了是运维遇到最多的故障之一。df -h看整体使用率du -sh *看当前目录下每个子目录占多大。分享一个处理磁盘满的完整流程执行df -h看到/分区 100%先du -sh /usr/*、du -sh /var/*逐层排查找到大目录后进去再du -sh * | sort -rh | head -20按大小排序直接找到最大的几个文件。清理时优先处理日志和临时文件千万别随便删其他文件避免误删。挂载 NAS 存储也是高频需求。NFS 挂载这里有个完整的步骤先查看服务端共享目录showmount -e NAS服务器IP。创建本地挂载点mkdir -p /data/nas。手动挂载mount -t nfs NAS服务器IP:/共享路径 /data/nas。验证df -h | grep nas确认挂载成功。写入/etc/fstab实现开机自动挂载格式大概是NAS服务器IP:/共享路径 /data/nas nfs defaults,noatime 0 0执行mount -a试验 fstab 配置有没有写错。这里最容易出问题的就是权限和防火墙。挂载后看到的内容是只读、或者根本报错“Permission denied”八成是 NFS 服务端导出的权限没配好或者本机防火墙没放行。建议先在客户端执行rpcinfo -p NAS服务器IP确认 nfs 服务正常再排查防火墙。3.4 进程与性能ps、top、free、vmstat 这一套进程管理是检查系统健康的关键。ps -ef看完整进程列表ps -aux按资源占用排序输出两者都能定位进程 ID。需要杀进程时kill -9 PID是强制杀kill -15 PID是优雅终止。top动态看 CPU 和内存占用进去按P按 CPU 排序、按M按内存排序按q退出。这是找“是谁把资源吃光了”的第一现场。free -h看内存。注意 Linux 的缓存机制很大一部分 Buff/Cache 是可以回收的不要看到用了 90% 就以为是泄漏。判断内存压力别光看 free要看 swap 是否增长以及vmstat 1里 si/so 两列是否频繁交换。我给性能排查列过一张参数速查表命令核心字段排查场景topload average、%CPU、%MEM整体负载高、进程异常free -havailable、swap内存不足、交换频繁vmstat 1r、b、si、so、usCPU 排队、内存换页、IO 等待iostat -x 1%util、svctm磁盘 IO 是否瓶颈ss -lntp监听端口、进程名端口冲突、服务未启动这套命令配合下来基本能回答“服务器为什么慢”这个大问题。4. 开发与学习场景从脚本到容器全家桶4.1 脚本基础变量、循环、定时任务写脚本是 Linux 能力的分水岭。不会脚本你每次都得手动敲命令会脚本重复工作就是一行./xxx.sh的事。脚本第一行是#!/bin/bash声明解释器。变量赋值用namevalue读取要加$name或${name}。条件判断用if [ -f $file ]; then ...; fi注意方括号里面有空格很多人第一次写就栽在这。循环最常用的是for i in $(seq 1 10); do ...; done。定时任务统一交给 crontab。crontab -e编辑、crontab -l查看、crontab -r删除。格式是“分 时 日 月 周 命令”。0 3 * * * /data/backup.sh表示每天凌晨 3 点执行一次备份脚本。注意脚本路径要写绝对路径脚本内涉及的环境变量有时不会自动加载最好在脚本开头显式定义否则定时任务跑出来的结果跟手动跑完全不一样。我踩过一个大坑写了个清理脚本手动执行很正常但 crontab 里不生效。后来发现是脚本在第一行没有完整声明 bash 路径因为 crontab 默认使用精简环境。处理方法是所有生产用脚本第一行都写#!/bin/bash并且不要依赖用户环境变量。4.2 版本协作git 高频命令开发环境绕不开 git。很多开发在 IDE 里点鼠标点习惯了一到服务器上就抓瞎。其实掌握几条就够日常用git clone 仓库地址拉取代码git status看当前改动git add .暂存所有改动git commit -m 说明提交git pull拉取更新git push推送git log --oneline看提交历史git branch -a列出所有分支git checkout -b 新分支名创建并切换合并分支git merge 分支名想撤销文件修改git checkout -- file或git restore file这里提醒一句在服务器上直接改线上代码前一定先git status看清当前分支和改动再决定用不用git pull --rebase。直接git pull遇到本地有未提交改动时经常会报冲突处理起来很烦。我的习惯是在服务器上只做拉取和部署不直接在服务器上写新功能。4.3 容器与中间件docker、redis-cli 高频命令容器环境已经是标配docker 命令必须手熟docker ps看运行中的容器加-a连停止的一起看docker logs -f 容器名跟日志docker exec -it 容器名 bash进入容器内部docker restart 容器名重启docker stop / start停止和启动docker build -t 镜像名:标签 .构建镜像docker images看镜像列表docker rmi 镜像ID删镜像docker-compose up -d一键启动一组服务进入容器排查问题时有个细节很多容器是最小化安装里面没有 vim、没有 curl。所以要么在容器内用apt-get install临时补装要么用docker inspect 容器名在宿主机侧看配置用docker cp 宿主机文件 容器名:/容器路径传文件。redis-cli 也是一个常用点。redis-cli -h 127.0.0.1 -p 6379连库redis-cli ping返回 PONG 说明服务正常。生产环境执行redis-cli keys *要非常谨慎大库下这条命令会阻塞整个 redis。真要检查数据量用redis-cli dbsize。查某一个 key 的值用redis-cli get key名。4.4 调试工具gdb 和 adb 的那些高频操作gdb 是 Linux 下 C/C 程序调试的标配。最常用的几个命令gdb ./程序名启动调试break 函数名或break 行号设置断点run开始运行next单步执行不进入函数step单步执行进入函数print 变量名查看变量值bt查看函数调用栈continue继续运行到下一个断点quit退出 gdb排查段错误时bt能直接打印崩溃时的调用栈定位是哪一行的野指针问题。如果是定位已经崩溃的程序可以打开 core dump 再用 gdb 分析gdb ./程序名 core文件。至于 adb做安卓开发或者嵌入式开发时用得较多。adb devices查看设备adb shell进入设备 shelladb install app.apk装应用adb logcat抓日志。真机调试时如果找不到设备先adb kill-server再adb start-server多半是 adb 服务卡住了。嵌入式 Linux 场景下还会遇到 DSA switch 驱动的调试这类通常要看ip link、bridge link和内核日志。我没有太强的嵌入式背景但从经验上讲调试思路跟服务器排查是一致的先确认设备状态再抓日志再查驱动上报的信息。5. 面试与系统概念Windows 对照与高频考点5.1 一张对照表搞定概念迁移很多人是从 Windows 转过来学 Linux 的最大的障碍是记忆习惯。我列一张对照表能帮你把旧知识迁移过来场景WindowsLinux查看目录内容dirls切换目录cdcd复制文件copycp移动文件movemv删除文件delrm查看当前目录cdpwd创建目录mkdirmkdir清屏clsclear查看 IPipconfigip addr或ifconfig查看进程tasklistps aux杀进程taskkill /F /PIDkill -9 PID编辑文件notepadvim或nano查找文件wherefind网络连通pingping对照表的意义不只是背单词而是帮你理解两种系统解决问题的大致方向。你会用dir就会用ls你会用ipconfig就会用ip addr。学习期间先拿熟悉的 Windows 行为做锚点慢慢过渡到 Linux 原生的思维方式。5.2 面试里常被问的IPC、链接与启动流程面试 Linux 岗位高频考点除了命令还会问机制。这些地方我也一并整理出来。进程间通信IPC管道、信号、共享内存、消息队列、套接字。一条命令能配合理解比如ps aux | grep nginx里的|就是管道。深入一点会问到shared memory和mmap的区别。实际运维中排查两个服务之间通信异常经常要检查是不是共享内存段没清理干净。硬链接与符号链接ln file link建硬链接ln -s target link建软链接。硬链接和原文件共享同一个 inode删掉一个不影响另一个软链接有点类似 Windows 的快捷方式目标删掉它就成了死链。面试常问区别运维中改配置也常用软链接切换版本。系统启动流程从 BIOS/UEFI 到引导加载程序再到 init 系统。CentOS 7 之后用 systemd 管理服务所以systemctl start nginx、systemctl enable nginx必须要知道。查看之前系统启动日志用journalctl -xb。这些概念光背不行要配合实际操作去理解。比如自己建一个软链接、读一次cat /proc/进程ID/status看进程状态比死记硬背有效得多。6. 常见问题与排查技巧实录6.1 命令找不到、权限不够先看这四个方向“command not found”是出现频率最高的错误提示。遇到这个情况先别慌按顺序排查命令是不是安装过比如htop没装就是 not found包管理器装一下即可。命令是否存在但不在 PATH 里/usr/sbin/下的命令普通用户可能用不了加上完整路径执行。是不是环境变量没生效改完/etc/profile后执行source /etc/profile。权限被限制ls -l看看执行权限位没有 x 权限就无法执行。6.2 NFS 挂载失败可能不是命令的问题挂载 NAS 命令本身很简单但失败的原因五花八门。我按概率排一下常见原因服务端没启动 NFS 服务showmount直接就报错。客户端没装 nfs-utils导致mount -t nfs不支持。防火墙没放行 2049、111 端口。挂载参数写错比如漏了nfsvers4。/etc/fstab 写错导致开机卡住这时可以进入紧急模式修复或先用mount -a验证再重启。我看过太多人在第四、第五个问题上折腾一整天。我的建议是先把手动挂载调通再写 fstab。手动都挂不上写成自动挂载只会更难排查。6.3 日志文件越来越大定期轮转怎么做日志爆盘是最常见的磁盘故障源。除了手动清理更推荐用系统自带的 logrotate。它的配置文件在/etc/logrotate.d/下为你的应用写一个配置/data/app/app.log { daily rotate 7 compress missingok notifempty copytruncate }这段配置的含义是每天轮转一次保留 7 份旧的压缩应用还在写日志时用 copytruncate 方式复制再清空避免服务句柄失效。配置好以后先用logrotate -d /etc/logrotate.conf干跑调试一下没问题再正式启用。6.4 六条避坑建议都是真金白银换来的最后分享几条我这些年攒下的经验不是什么文档里都会写的删除前先 mv 到临时目录观察一天再删。这招救过我很多次。批量命令前先 echo 或 dry-run 验证。比如要批量重命名文件先跑一遍只打印不改动确认没问题再真正执行。修改系统配置文件前先备份。cp file file.bak一行命令关键时候能让你免于重装系统。不要在高峰期执行大范围 find、grep 扫描全盘。CPU 和 IO 被拉满用户就卡住了。用nohup 命令 运行后台任务时注意确认输出重定向。不重定向的话默认输出到 nohup.out时间长了照样把磁盘撑满。连接服务器务必使用密钥认证少用密码登录。CentOS 和 Ubuntu 最近的版本都开始默认禁止密码登录这个趋势要跟上。这些经验看着零碎但每一条背后都有真实事故的教训。工具用法过一两个月会生疏这类思维习惯会一直留着帮你省掉无数加班时间。我自己留这份速查表的方式很简单放在~/cheatsheet/目录下用 Markdown 写好遇到问题先翻一遍再结合man命令看详细说明。时间长了哪些命令常用、哪些参数最顺手你会形成自己的肌肉记忆。最后想提醒一句命令只是工具真正值钱的是你排查问题时的思路。先把这几十条命令用熟再渐渐扩充你的 Linux 功底就会像滚雪球一样越来越厚。