打开终端敲上几行tail -f、grep、ps aux这基本就是运维开发每天的真实写照。我见过不少刚入行的同事手里捧着一本 Linux 命令大全翻来翻去可真到线上出问题的时候反而不知道先敲哪条命令。原因很简单命令是死的场景是活的只有把命令和实际任务结合起来才算真正掌握 Linux 的干活方式。这篇内容就是围绕实际工作这四个字展开的。不堆概念不讲源码全部是我在日常巡检、排障、部署、日志分析里反复用到的命令按照文件操作、日志检索、资源排查、网络诊断、服务管理这几个方向重新梳理。如果你正在做运维、后端开发、SRE或者准备面试这份汇总可以直接当工作手册来用遇到问题翻对应章节就行。1. 通用命令思维先学会怎么问Linux1.1 拿到陌生命令先看help和man很多人有个坏习惯遇到不会用的命令直接上网搜索复制一段下来就敲。说实话解决临时问题可以这么干但想真正提升效率得养成先查本机文档的肌肉记忆。# 命令自带简要帮助适合快速查看参数 ls --help # 完整手册适合深入了解选项、退出码、示例 man ls # 精简版帮助很多命令也支持 ls -h我自己的习惯是先用--help看有没有我想要的参数如果觉得信息不够再看man的对应章节。比如man本身分 8 个章节1 是用户命令5 是配置文件格式8 是系统管理命令查配置文件格式的时候直接man 5 sshd_config比在网上一页页翻高效多了。1.2 命令历史是你最好的记忆库工作中命令敲得多了总有一些又长又复杂的记不住比如带一堆参数的生产环境排查命令。这时候 Linux 的历史记录功能就是你的外脑。# 查看最近 100 条历史命令 history # 快速执行历史中的第 123 条 !123 # 执行最近一条以 grep 开头的命令 !grep # 反向搜索历史命令输入关键字即搜即用 Ctrl R我实际用Ctrl R的频率比history高得多。线上环境操作前我经常先用它搜出之前的执行命令确认参数避免手滑敲错。另外提醒一句操作生产环境之前可以先执行history看一下你是否曾经敲过某条命令如果里面有敏感信息记得用history -c清掉当前会话记录避免离职交接或者终端复用的时候泄露信息。1.3 管道思维把单条命令变成工作流Linux 最强大的地方在于组合能力而不是单个命令。|管道符可以把前一个命令的输出交给下一个命令处理这种思维方式直接决定你的运维效率。# 统计当前目录下文件数量 ls -l | grep ^- | wc -l # 查看系统监听端口过滤出 nginx 相关 ss -tlnp | grep nginx # 查看内存占用最高的 5 个进程 ps aux --sort-%mem | head -5这类组合命令背后其实是三种基本功过滤、统计、排序。掌握了这几个动作遇到任何我要从一堆输出里找到关键信息的需求都能现场拼出一条组合命令来。我见过不少高手排查问题本质就是在不停地组合这些基础命令把系统输出一层层剥开直到看到真相。2. 文件与目录操作每天花时间最多的地方2.1 磁盘空间定位三板斧ls、du、df排名第一的实际场景是磁盘满了服务写不了日志于是我把时间花在寻找大文件上。这套操作有固定套路先全局看分区占用再层层深入定位目录。# 查看各分区使用情况-h 人性化显示 df -h # 查看当前目录下各子目录占用大小找出磁盘杀手 du -h --max-depth1 | sort -rh # 直接定位大于 500M 的文件 find /data -type f -size 500M -exec ls -lh {} \;df -h是第一步它告诉你根分区、数据分区哪块告急。然后紧接着用du --max-depth1逐层往里面查sort -rh按大小倒序排列后大文件瞬间水落石出。如果是日志文件占的空间还可以配合find ... -mtime 7来识别 7 天前的旧日志。如果我需要快速清理在 7 天前的.log文件可以执行find /var/log -name *.log -mtime 7 -delete。这个命令会直接删除文件建议先不带-delete跑一遍确认输出的列表无误之后再加上。生产环境的删除操作宁可多花一分钟验证也不要不小心把目录一起干掉。2.2 查找文件别只用find试试locatefind功能强大但性能开销也高全盘遍历一遍可能要几分钟。如果只是想快速找某个名字已知的文件我会优先用locate它基于预建索引响应速度是秒级。# 更新数据库新装系统或者刚创建大量文件后先跑一次 updatedb # 快速查找包含 nginx.conf 的文件 locate nginx.conflocate的代价是它不一定实时刚创建的文件可能不在索引里。所以我的标准姿势是紧急排查、能接受稍慢的结果用find平时找文件、确认某个路径下有哪些同类文件直接locate效率高一个量级。2.3 归档压缩别把tar参数记混生产环境的日志归档、代码发布备份tar几乎是绕不开的。关键是它参数一多就容易混乱特别是压缩格式对应的参数。# 打包并 gzip 压缩 tar -czvf backup.tar.gz /data/app # 解压 tar.gz tar -xzvf backup.tar.gz # 只查看压缩包内容不解压 tar -tzvf backup.tar.gz # 追加文件到已有 tar 包不支持压缩格式 tar -rvf backup.tar /newfile.txt一个小细节-c创建、-x解压、-z走 gzip、-v显示过程、-f指定文件名。f后面一定是文件名而且要放在最后。我见过有人把参数写成tar -cvfz结果z被当成文件名命令直接报错。这个位置问题在实际操作中比想象中常见得多。2.4 文件内容处理vim 的三个效率习惯vim 是 Linux 环境默认编辑器大部分人只会i、:wq这远远不够。我整理了自己日常最常用的一套组合能让文本编辑效率提升特别多。# 命令行模式下翻屏 Ctrl d # 向下翻半屏 Ctrl u # 向上翻半屏 # 快速跳转 gg # 文件头 G # 文件尾 :set nu # 显示行号 :123 # 跳到第 123 行 # 查找与替换 /error # 查找 errorn 下一个N 上一个 :%s/old/new/g # 全文替换实际排查日志时最常用的是tail加vim的配合先用tail -n 200 app.log看滚动输出然后用vim打开完整日志:123跳到具体行号再配合/关键词搜索上下文。这套组合给我节约的时间保守估计占日常排查的三成以上。3. 日志分析与检索从茫茫信息里抓关键线索3.1tail动态跟踪日志文件运维排障的第一反应就是看日志。日志文件一直在变化tail可以持续输出新增内容这才是生产环境的标准用法。# 实时跟踪日志CtrlC 退出 tail -f /var/log/nginx/access.log # 查看最后 200 行常用于日志量大、不想刷屏的情况 tail -n 200 /var/log/app/app.log # 跟踪并同时显示行号 tail -f -n 50 /var/log/app/error.log | awk {print NR, $0}实际工作中我经常需要同时盯多个日志文件比如应用日志和错误日志一起看。推荐用tail -f file1.log file2.log屏幕会分别带文件名显示新增内容哪个文件有变化一目了然。3.2grep日志检索的核心武器单靠tail盯日志效率太低公式是先用grep把关键信息捞出来再配合上下文查看。这里有几个高频参数我几乎每天都在用。# 精准匹配 error忽略大小写 grep -i error /var/log/app/app.log # 显示匹配行前后各 5 行内容上下文一目了然 grep -C 5 Exception app.log # 统计错误出现次数 grep -c ERROR app.log # 递归搜索整个目录下的所有日志 grep -r timeout /var/log/app/ # 只输出匹配部分而不是整行抓 IP、抓时间戳特别有用 grep -o [0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\} access.log | sort | uniq -cgrep -C 5是我最推荐新手开始使用的参数。排查程序报错的时候只看 ERROR 那一行往往不知道原因错误前后的日志才能还原现场。配合-r可以批量搜索比如所有服务模块都往同一个目录写日志一条命令就能定位到具体是哪个服务在报错。3.3awk与sed日志分析的进阶组合如果说grep是筛选那awk就是字段级别的处理。比如 nginx 访问日志的格式一般是IP 时间 请求 状态码 响应字节如果想统计某个接口的请求量和平均耗时awk是最顺手的工具。# 统计访问日志中各个状态码的数量 awk {print $9} access.log | sort | uniq -c | sort -rn # 统计某个接口的请求总量 awk $7 /api/user/info {count} END {print count} access.log # 按分钟统计请求量 awk {print $4} access.log | cut -d: -f1-2 | uniq -csed则更多用在日志清洗和文本替换上。比如想临时把日志里的密码字段打码或者批量把某个 IP 替换成内网地址再分析# 把日志中所有 192.168.1.10 替换为 192.168.1.100 并输出到新文件 sed s/192.168.1.10/192.168.1.100/g access.log access_new.log # 删除日志中的空行 sed /^$/d app.logawk和sed的语法颇有门槛我的建议是先记住几个固定模板解决 80% 的问题。比如awk {print $N}取第 N 列、sed s/旧/新/g做替换这两个模板学会之后再碰到复杂需求边查边用效率提升会非常明显。3.4journalctlsystemd 日志的统一入口现在主流发行版都用 systemd 管理服务日志也趋向统一走journalctl。这个命令比传统文件日志多了一个维度可以按时间、服务、优先级过滤。# 查看 sshd 服务最近 30 分钟日志 journalctl -u sshd --since 30 minutes ago # 实时跟踪某个服务的日志 journalctl -u nginx -f # 查看指定时间段的系统日志 journalctl --since 2025-01-01 00:00:00 --until 2025-01-01 08:00:00 # 查看内核日志 journalctl -k我经历过一个典型场景某个服务启动失败但服务自己的日志什么都没写最后是journalctl -u 服务名里找到了启动脚本报的权限错误。这类排障如果没有 journalctl可能一直在错误的方向上反复看配置文件。4. 系统资源排查CPU、内存、磁盘、进程4.1top与htop进程与资源的可视化窗口服务器响应变慢第一反应就是登上去执行top看哪条进程吃掉资源。不过top的原始输出对新手不太友好我更关注几个关键指标。# 进入 top 后按 P 按 CPU 排序按 M 按内存排序 top # 只查看指定 PID 的资源占用 top -p 12345 # 加载 1 秒采样只输出一次结果适合脚本采集 top -b -n 1 | head -20top头部有个 load average它表示 CPU 上等待运行的任务队列长度。如果这个值超过 CPU 核心数的 70% 以上基本可以判断负载偏高。再往下看%CPU高说明进程在疯狂计算%MEM高说明内存吃紧二者处理思路完全不同。htop是top的增强版支持颜色高亮、鼠标操作、树形视图如果系统允许装我建议直接把它默认安装上。4.2free内存分析不能只看总量经常有人看到free -h输出 available 只剩几百兆就开始慌。实际上 Linux 的内存管理机制比较特殊很多已用内存其实是缓存可以随时释放给应用使用。正确姿势是重点看 available 这一列它就是实际可用的内存估算值。# 人性化显示内存使用 free -h # 以 MB 为单位适合脚本解析 free -m # 每隔 3 秒刷新一次持续监控 free -s 3判断内存是否真的不足我的经验是看 available 是否持续下降同时结合vmstat的 si/so 列。如果 swap 的换入换出si/so数值一直不为零说明物理内存确实不够了这时候才需要考虑加内存或者调优 JVM 等内存大户的参数。4.3ps进程快照与状态分析ps aux是经典中的经典但实际用的时候我很少直接裸跑ps aux因为输出行数太多全是噪声。更多是配合grep精准定位。# 查找某个进程的详细信息 ps aux | grep nginx # 查找某个进程的 PID pgrep -f app.jar # 查看进程的父子关系 ps -ef | grep java # 查看进程打开的端口、连接等信息 ss -tlnp | grep java排查端口冲突是ps的典型场景。新起的服务一直报端口被占用先ss -tlnp | grep 端口号找到占用进程的 PID再用ps -p PID -o pid,cmd查看是谁。这条链路是我排查端口类问题永远的第一步。4.4kill与信号优雅停止与强制杀掉很多人以为kill就是杀进程实际上它只是发送信号。不同的信号决定了进程死亡的方式这一点在生产环境特别重要。# 优雅退出给进程时间保存状态、清理资源 kill 12345 # 强制退出只能作为最后手段 kill -9 12345 # 重启配置像 nginx、sshd 这类服务不需要完全停止 kill -HUP 12345我的原则是能优雅退出绝不强制杀。像数据库这类有状态的服务强制-9可能导致数据文件损坏。平时规范操作推荐用systemctl stop 服务名来停止服务而不是直接找 PID 去kill。只有在服务彻底卡死、正常停止无响应的极端情况才用-9作为兜底。5. 网络排查端口、连接、连通性5.1ss替代netstat端口监听与连接状态老的运维习惯是用netstat但新版本 Linux 上ss才是性能更好、信息更全面的工具。日常排查端口监听、连接数、异常连接我都用它。# 查看所有监听端口 ss -tlnp # 查看所有 TCP 连接 ss -tanp # 统计各状态的连接数 ss -tan | awk {print $1} | sort | uniq -c # 查看某个端口的连接情况 ss -tanp | grep 8080ss -tan输出里的LISTEN表示服务正常监听ESTAB表示已建立连接TIME_WAIT表示主动关闭后的等待状态。TIME_WAIT 数量特别多的时候往往是短连接请求量太大导致的这种情况一般需要调整内核参数net.ipv4.tcp_tw_reuse而不是盲目重启服务。5.2ping与telnet快速判断网络层与端口层问题网络不通和端口不通是两码事。我的排查顺序是先ping验证网络层再telnet或者nc验证端口层。# 测试连通性-c 指定次数 ping -c 4 192.168.1.100 # 测试目标端口是否开放 telnet 192.168.1.100 8080 # 更轻量的端口测试工具 nc -zv 192.168.1.100 8080如果ping通了但telnet失败说明网络通目标主机的端口没监听问题出在应用层。如果ping也不通先排查防火墙、路由、网卡这些链路问题。5.3curl接口测试与请求排查后端开发常用的curl不只是下载文件工具它在接口联调和排障时的作用被严重低估。# 查看响应头信息判断服务端是否正常返回 curl -I http://localhost:8080/health # 指定请求方法并输出完整响应 curl -X POST http://localhost:8080/api/login -d {name:test} -H Content-Type: application/json # 模拟慢响应场景-w 输出耗时详情 curl -o /dev/null -s -w 连接耗时:%{time_connect}s 总耗时:%{time_total}s\n http://localhost:8080/index.html # 携带 Cookie 访问 curl -b sessionabc123 http://localhost:8080/user/info我最常用的是第三个用法接口在浏览器里访问正常但线上出现大量超时用-w直接输出各阶段耗时就能快速分辨是 DNS 解析慢、TCP 握手慢还是服务端响应慢。这比拿着浏览器开发者工具去排查服务器端问题要精准得多。5.4iptables与防火墙服务访问不了的常见元凶很多时候服务明明在监听访问却始终超时问题出在防火墙规则。虽然现在很多云厂商有安全组但服务器本机的 iptables 仍然可能成为拦截点。# 查看当前防火墙规则 iptables -L -n --line-numbers # 禁止某个 IP 访问本机 iptables -A INPUT -s 1.2.3.4 -j DROP # 删除某条规则先查询行号再删除 iptables -D INPUT 3另一个常见的防火墙入口是 firewalld 或者 ufw不同发行版命令不一样。我建议排查顺序是先确认服务在监听ss -tlnp再确认服务器本机防火墙没有拦截iptables -L最后再查云安全组这样可以快速缩小问题范围。5.5 DNS 排查getent与dig域名解析出错的表现是服务能 ping 通 IP但访问域名失败这类问题在对接外部依赖时很常见。常用命令是两个方向# 查看系统实际使用的 DNS 解析结果 getent hosts api.example.com # 指定 DNS 服务器查询绕过系统配置 dig 8.8.8.8 api.example.com # 查看 DNS 解析的详细过程 nslookup api.example.comgetent的优势在于它走的是系统/etc/nsswitch.conf的完整解析链包含 hosts 文件和 DNS 服务器最贴近应用的真实解析结果。dig的优势在于可以指定上游服务器验证定位到是系统配置问题还是上游 DNS 问题这一区分在实际排障中很关键。6. 服务管理与效率技巧systemd、别名与快捷键6.1systemctl替代繁琐的 init 脚本现代 Linux 管理服务基本都是 systemd核心命令就几个但要注意每个命令的具体含义。# 启动、停止、重启、查看状态 systemctl start nginx systemctl stop nginx systemctl restart nginx systemctl status nginx # 设置开机自启 / 取消开机自启 systemctl enable nginx systemctl disable nginx # 查看服务启动失败的详细信息 systemctl status nginx -l # 重新加载配置文件不重启进程 systemctl reload nginxsystemctl reload和restart有本质区别。reload 只是让服务重新读取配置不中断业务restart 会重启进程中断连接。像 nginx 这样的服务改完配置推荐先nginx -t校验语法再systemctl reload既安全又对业务无感知。6.2alias与.bashrc把高频命令变成自己的快捷键我见过不少工程师的终端效率很高秘诀就是大量使用别名把长命令变成短命令。这完全可以在你自己的账号下做。# 定义常用别名 alias llls -lh alias lals -A alias grepgrep --colorauto alias qfindfind / -name # 查看已有别名 alias # 写进配置永久生效 echo alias jcjournalctl -u ~/.bashrc source ~/.bashrc我自己的.bashrc里还加了一条alias nowdate %Y-%m-%d %H:%M:%S配合日志追踪特别好用。别名最重要的价值是让常用且易错的命令固定下来你不需要每次记忆完整参数容错率一下就上来了。6.3 组合操作符、||、;的适用场景这三个符号看似简单用错场景很容易埋雷。# 前一条成功后才执行后一条常用于编译成功后继续部署 make make install # 前一条失败时才执行后一条常用于备份失败后告警 tar -czf backup.tar.gz /data || echo 备份失败请检查 # 无论前一条是否成功都执行常用于清理临时文件 rm -rf /tmp/build; echo 清理完成是最实用的它保证了操作之间有逻辑顺序。比如先进入目录再打包可以写成cd /data tar -czf app.tar.gz app/如果目录不存在cd失败整个打包就不会执行避免在错误目录下打包出空文件。7. 实用对比Linux 与 Windows 命令对照速查7.1 高频命令对照表很多从 Windows 转过来的同事总觉得 Linux 命令难记本质上只是不熟悉两个系统的名词差异。我给团队做培训时整理过一张对照表效果不错。功能Windows CMDLinux说明列目录dirls -lLinux 加-l才能看详细属性清屏clsclear快捷键CtrlL效果一样复制文件copycpLinux 复制目录需要加-r移动文件movemv也用于重命名删除文件delrmLinux 删除即彻底删除没有回收站查看进程tasklistps auxLinux 列表信息更丰富杀进程taskkill /F /PIDkill -9 PID注意-9的风险查看端口netstat -anoss -tlnp都能看占用端口的 PID测试网络pingping参数略有差异文件内容查看typecat/lessless支持翻页和搜索历史命令doskey /historyhistoryLinux 历史能力更强获取帮助help 命令命令 --help/man 命令参数不同系统信息systeminfouname -aLinux 简略cat /etc/os-release更详细记住一个核心差异Windows 删除文件进回收站还能反悔Linux 的rm -rf是直接抹掉没有后悔药。我从带新人的经历来看Linux 新手最容易出事故的操作就是删除类命令所以安全习惯尤其重要。7.2 Windows 转 Linux 的思维转变除了命令名不一样更关键的是理念差异。Windows 下你的第一反应可能是打开图形界面点点点而 Linux 的强项是写命令完成自动化。比如批量重命名一批文件Windows 图形界面可能要点半天Linux 一条rename或for循环轻松搞定。另一个差异是权限模型。Windows 用管理员权限弹窗Linux 用普通用户加sudo。这个设计让日常操作尽量以普通身份运行只有需要系统级变更时才临时提权。养成这个习惯后误操作伤到系统核心文件的概率会低很多。8. 高频面试与实战细节常见问题和避坑经验8.1 Linux 面试常见命令题速看结合这几年带人和面试的经验Linux 命令方向的高频问题其实就是几个场景的变体查找大文件、查看端口占用、统计日志错误数、手动排查 CPU 飙升。我整理成一张快速问答表面试/实际场景推荐命令组合关键点磁盘快满了找大文件df -h再du -h --max-depth1逐层下钻先全局后局部避免一上来全盘扫描某个端口被占用ss -tlnpgrep 端口统计错误日志数量grep -c ERROR app.log注意大小写必要时加-iCPU 飙高定位嫌疑进程top按P排序再top -p PID结合strace或日志确认具体原因快速找到昨天修改过的文件find /data -type f -mtime -1-mtime -1表示 24 小时内实时跟踪多个日志tail -f a.log b.log输出带文件名前缀方便区分判断本机 DNS 是否正常getent hosts 域名优先于ping更能反映系统解析链状态服务起不来看系统日志journalctl -u 服务名 -n 100结合-l看完整输出8.2 生产环境安全操作习惯最后分享几条我在实践中用过的经验也是我要求团队成员必须遵守的底线。加锁命令删除、清空、格式化这类危险操作执行前先预演。find ... -delete之前先不带-delete跑一遍rm带-i让系统逐个确认必要时在.bashrc里alias rmrm -i给手滑留一条缓冲。输出重定向的坑会覆盖文件才会追加。我见过有人把采集脚本的输出写错重定向符结果把积累了一个月的报表直接清空。这类错误不报任何错极难发现只能在习惯层面避免。不要用cat查看大文件一个 5GB 的日志文件cat会瞬间刷屏严重时直接把终端拖死。正确做法是less、tail -n或者grep定位宁可多看几眼也不要用cat硬莽。环境变量与路径排查命令明明存在但执行不了的问题先确认 PATH 是否正确。我之前遇到过用户自定义安装了新版 Python但系统默认调用的还是老版本所有依赖新版本的脚本全挂。遇到这类问题which 命令、echo $PATH、ls -l /usr/local/bin/三项检查基本能快速定位。8.3 这条路径还可以继续扩展Linux 命令学到这个阶段其实已经具备解决日常问题的能力了。如果想继续深入我个人的建议是可以往三个方向延展一是 Shell 脚本编程把常用命令组合成自动化脚本比如日志清理、服务巡检、批量部署二是网络排查进阶比如tcpdump抓包分析、路由跟踪三是容器化运维Docker、Kubernetes 都建立在 Linux 命名空间和控制组这两个基础能力之上命令层面很多思想是相通的。我在实际使用中的体会是命令学习最大的瓶颈不是记忆力而是场景感。同一句grep ERROR app.log它在日志检索场景里是统计错误在接口调试场景里是排查参数错误在安全审计场景里可能是筛选异常登录记录。所以不要孤立地背命令而是要带着具体问题去实践把命令变成你解决实际问题时的条件反射这才是运维开发人员真正高效的状态。