简介一份面向Linux初学者、进阶用户及服务器运维人员的系统命令速查手册内容覆盖文件与目录管理、系统监控与用户权限、网络配置与远程访问、软件包管理等四大核心模块并针对Debian/Ubuntu、CentOS/RHEL、Fedora、Arch等主流发行版的包管理差异做了对照说明。资源以单个docx文档交付体积约15KB轻量易携带目前已积累129人学习。文档中每条命令均配有简明示例如ls的-a/-l参数、tar的打包压缩用法、grep递归搜索、crontab定时任务、iptables规则查看等方便对照练习与排错同时补充了which、alias、history等高频辅助命令可有效提升日常操作效率。无论是新手入门建立知识框架还是运维人员作为快速查询手册都具备实用价值。1. Linux 系统常用命令为什么同样是排查问题有人三分钟有人三十分钟Linux 系统常用命令这个标题看着像一本命令字典但真正拉开差距的从来不是背了多少条命令而是知道哪些命令可以组合起来用。我帮同事排查一个服务启动失败问题时他在目录里来回点了五分钟才找到日志我用一条tail -f加上grep在十秒内定位到报错行——区别不在手速而在理解命令的配合方式。这篇笔记不打算把命令手册抄一遍而是把日常排查、运维、脚本编写里最高频的命令讲透参数怎么设、什么时候用它、最常在哪里翻车。适合刚上手 Linux 的开发者、需要自己查日志和进程的运维新手以及想把命令行真正变成生产力工具的从业者。2. 文件与目录操作路径规则、查看技巧与复制场景的参数差异2.1 路径解析规则为什么你 cd 不进去、cp 找不到文件文件命令是 Linux 里使用频率最高的命令族但很多人第一个坑就栽在路径上。常见做法是先pwd确认当前位置再决定用绝对路径还是相对路径。绝对路径从/开始在任何目录下都有效相对路径依赖当前所在目录脚本里最容易出问题——你在项目目录下写的cp config.ini ../backup/换一个目录调用脚本目标位置就完全变了。# 打印当前工作目录 pwd # 回到上一个工作目录适合在两个目录间反复切换 cd - # 回到当前用户的家目录 cd ~ # 用上一级目录和当前目录组合相对路径 cd ../ cp ./config.ini ../backup/cd -在日常排查时非常实用你在/var/log看日志切到/etc改配置一条cd -就能回到刚才的目录不需要重新敲路径。~代表当前用户的家目录但要留意一个陷阱脚本用sudo执行时~解析成 root 的家目录而不是你当前用户的家目录这会让很多写死的路径失效。我的习惯是脚本里不用~改成显式的$HOME或绝对路径避免 sudo 环境下行为不一致。路径解析还有一个常被忽略的点/开头的绝对路径不会被别名或当前目录影响适合写进计划任务和执行脚本里。相对路径则要关注“当前目录是哪里”这在后面的避坑章节还会提到。2.2 ls 与 find从“能看见”到“能找到”ls是所有新人第一条接触的命令但多数人只用默认输出浪费了它定位文件的能力。排查文件时间、大小、权限时组合参数比用鼠标点开图形界面快一个量级。下面是我常用的几个参数组合命令作用典型场景ls -lh人类可读的文件大小看大文件占用ls -t按修改时间倒序找最近改动的文件ls -S按文件大小倒序定位占用大的文件ls -la | head含隐藏文件的头部列表看目录里最近新增了什么# 递归查找名字包含 error 的文件忽略大小写 find /data/logs -iname *error* -type f # 找出 7 天内修改过的配置 find /etc -type f -mtime -7 # 找出超过 100M 的文件 find /data -type f -size 100M # 找出空目录配合清理脚本很有用 find /data -type d -emptyfind和ls的分工不一样ls适合在一个目录里快速浏览find适合在整棵目录树里按条件定位。-mtime -7中的数字表示“多少天以内”正数表示多少天以前这个正负号经常让人搞反。-size 100M里的表示大于小于则直接用负数或没有符号写脚本时先跑一遍find确认匹配结果再进入删改步骤能避免很多误操作。2.3 cp、mv、rm 与 rsync复制场景怎么选参数复制和移动是所有运维操作的起点参数选错轻则覆盖文件重则丢失数据。先看几个高频用法# 保留权限和时间戳递归复制备份目录时用 cp -rp /opt/app /data/backup/ # 目标已存在时不覆盖批量合并时很安全 cp -n source.txt dest.txt # 仅在源文件更新时复制适合增量同步小目录 cp -u source.txt dest.txt # 移动前逐个确认防止误覆盖同名文件 mv -i old.conf new.conf-p保留的是权限、属主和时间戳日志轮转和配置备份必须带上。-n在不希望覆盖任何已有文件时是安全网但它和-u冲突两个不能同时用。mv -i的交互确认看起来烦但在批量移动时能避免同名覆盖——有一次我把一批配置移动到新目录同名文件被静默覆盖后面排查了很久才发现是这里的问题。目录级别的同步使用rsync更可靠它支持断点续传和只传输变更部分# -a 归档模式保留属性-v 显示过程--delete 删除目标端多余文件 rsync -av --delete /opt/app/ /data/backup/app/--delete是把双刃剑它的本意是让目标目录和源目录完全一致但如果你在源目录误删了一个文件同步后目标目录里也没有了。我的习惯是第一次同步不加--delete先跑-av看对比结果确认无误后再决定要不要加。另外注意源路径末尾的/rsync -av /dir /backup和rsync -av /dir/ /backup的结果不同——前者会创建一个dir子目录后者把内容直接同步到目标目录。3. 文本处理三件套grep、sed、awk 让日志直接变成答案3.1 grep匹配、递归与上下文日志文件是 Linux 排障的主要线索来源而grep是打开线索的第一把钥匙。默认的简单匹配只能告诉你“有没有”加上参数之后才能回答“在哪个文件、哪一行、旁边是什么”。这几个参数是我在生产环境中最常用的# 递归搜索指定文件类型忽略大小写显示行号 grep -rn --include*.py def run ./src # 打印匹配行的前 2 行和后 5 行定位异常上下文 grep -n -B 2 -A 5 Traceback app.log # 扩展正则同时匹配多个关键词输出最后 20 条 grep -E ERROR|FATAL app.log | tail -n 20-r让 grep 进入递归模式--include限定文件类型在代码库里找函数定义或配置项时比拿编辑器全局搜索更快。-B和-A分别表示匹配行之前和之后的上下行数看异常堆栈时必须带上否则只看到一行报错看不到调用路径。-E启用的扩展正则支持|多选一次匹配多个关键词比写多条 grep 再合并更清爽。grep 与管道配合时需要留意缓冲问题grep在输出到终端时是行缓冲但输出重定向到管道或文件时变成块缓冲tail -f实时追加日志时会出现“日志已经刷了很多grep 这边半天没动静”的现象这个问题在第 5 章的避坑部分会展开讲。3.2 sed流式替换与原地修改sed最常见的两件事是替换和按行范围打印。它不加载整个文件到内存而是逐行处理所以对几百 MB 的大日志文件也能保持很低的资源占用。这个特性决定了它比编辑器更适合在批量环境里改配置。# 替换 nginx.conf 中的 IP同时备份原始文件 sed -i.bak s/192.168.1.10/192.168.1.20/g nginx.conf # 只打印第 10 到 20 行快速查看某段日志 sed -n 10,20p app.log # 删除空行清洗 hosts 或配置文件 sed -i /^$/d hosts.txt-i.bak的意思是原地修改并生成.bak备份这个备份是批量替换的后悔药——很多次我替换完才发现正则写错了靠.bak一行命令就恢复了现场。不加g时 sed 只替换每行第一个匹配加了g才是全局替换这个细节经常被忽略。-n配合p的组合只有匹配和指定范围才打印不加-n时 sed 默认会把所有行都打印出来输出会混入大量无关内容。用 sed 修改生产配置时我的建议是三层保护先grep -n确认目标内容存在再执行替换替换完立刻用grep验证结果。顺序执行三条命令比直接把-i写进一步操作要稳妥得多。3.3 awk按列统计的日志分析利器awk 适合把日志里的一行拆成多列再做统计和条件过滤。默认按空白空格或 Tab分割这个行为在访问日志上直接可用。# 打印访问日志第一列通常是客户端 IP和最后一列 awk {print $1, $NF} access.log # 按第 9 列HTTP 状态码统计请求数量按次数降序排列 awk {count[$9]} END {for (code in count) print code, count[code]} access.log | sort -rn # 求第 3 列的数值总和 awk {sum $3} END {print sum} data.txt # 带条件过滤只处理第 4 列大于 1000 的行 awk $4 1000 {print $1, $4} data.txt$NF表示当前行的最后一个字段NF本身是字段数量这两个变量在列数不固定的日志里很好用。count[$9]用数组做计数器END块在所有行处理完后执行最终循环打印每个状态码的出现次数。awk 默认按连续空白分割如果字段以逗号或竖线分割需要-F指定例如awk -F, {print $1}这个参数常被忽略。awk 和 sed 的分工也很清晰sed 擅长按行做替换和删除awk 擅长按列做统计和条件过滤。遇到“找出错误日志最多的 IP”这类需求grep先过滤出错误行再管道给awk统计第三列两行命令就能完成原本需要在编辑器里折腾半天的分析。4. 进程、资源与日志把排查链路串成一条命令4.1 ps 与 top定位 CPU 与内存消耗者服务变慢、负载升高这类问题第一步一定是找到谁在消耗资源。ps查看的是命令执行瞬间的进程快照适合做一次性的状态采集top是持续刷新的动态视图适合盯着某个进程看变化。# 查看所有进程并按 CPU 使用率降序排列 ps aux --sort-%cpu | head -n 10 # 查看与某服务相关的进程 ps -ef | grep mysqld | grep -v grep # 交互式查看top 里按 P 按 CPU 排序按 M 按内存排序 topps aux --sort-%cpu中aux里的x会列出所有进程包括没有终端控制的后台进程--sort后面加负号表示降序。head -n 10取前 10 行第一眼就能看到最占用 CPU 的进程。ps -ef | grep是查找特定进程的经典写法末尾的grep -v grep用来过滤掉 grep 进程自己不加这一节结果里会混入一条无关记录。top 进入交互模式后按大写P键按 CPU 排序、按M键按内存排序按k可以输入进程号直接发信号适合在终端里快速处理反应缓慢的进程。4.2 free、df、du判断资源边界内存和磁盘是 Linux 服务最常见的瓶颈。free、df、du三个命令分别回答“内存还剩多少”“磁盘分区还剩多少”“哪个目录占了多少”三个问题。# 人类可读单位显示内存总量与剩余 free -h # 查看挂载点分区占用和文件系统类型 df -hT # 查看当前目录下各子目录的占用按大小倒序 du -sh */ | sort -rh | headfree -h里的 used 列包含了文件缓存cache这部分内存在内存紧张时会被内核自动回收因此不能直接用 used 判断内存是否真的不够。真正需要关注的是可用量也就是 available 列。df -hT的-T显示文件系统类型判断某个目录是不是网络存储时很有用。du -sh */只统计当前目录下一级子目录的大小管道给sort -rh后就能一眼看出哪个目录占空间最多。有一个常见误用df看某个目录的占用很小但服务依然报磁盘满。这种情况通常是有进程打开了已被删除的文件文件句柄还存在占用的空间没有释放。用lsof | grep deleted找占用句柄的进程重启或让它重新打开文件后空间才会回来这个坑在清理日志时特别常见。4.3 把命令组合成一条排查链路单条命令解决的是单一问题真正的高效是把命令用管道和变量串起来。日志实时跟踪和进程监控是两个典型的组合场景# 实时跟踪日志中的 ERROR并保持行缓冲输出 tail -f app.log | grep --line-buffered ERROR # 获取指定服务的进程号再进入 top 的定向监控 pid$(pgrep -f server.jar) top -p $pid第一条命令里tail -f持续输出日志grep --line-buffered保证新日志到达后立即刷新而不是攒在缓冲区里这在排查线上问题时能帮助实时捕捉错误出现的时间点。第二条命令用pgrep -f按完整命令行匹配拿到进程号top -p只监控这一个进程避免在有几十个进程的机器上找不到目标。注意pgrep -f server.jar的匹配范围是完整命令行如果机器上有多个相同参数的服务需要用更精确的关键词区分否则拿到的进程号可能不是你想盯的那一个。5. Linux 命令避坑指南5 个最容易翻车的现场5.1 rm -rf 加空变量差点删掉整个用户目录现象脚本执行rm -rf $dir/由于$dir未赋值命令实际变成了rm -rf /或rm -rf ~等超出预期的路径。原因变量在脚本执行时未被正确初始化或者前一步的赋值命令失败但脚本没有退出导致空变量继续参与后续命令。这是 Linux 运维里后果最严重的经典事故很多人第一次遇到时都在测试机上但这习惯用在生产环境就是事故。解决脚本开头加set -u让未定义变量直接报错退出删除前打印要删除的路径人工确认更稳妥的做法是给变量提供默认值再用[ -n ]判断非空#!/bin/bash set -u target${DELETE_DIR:-/data/backup} [ -n $target ] rm -rf $targetset -u是脚本保护的第一道防线未定义变量出现时立即终止执行。${DELETE_DIR:-/data/backup}是参数展开语法前半部分是变量名:-后面是未定义时使用的默认值。最后一行[ -n ]再确认一次非空三层保护把空变量导致的误删概率降到最低。5.2 tail -f 管道 grep 后没有实时输出现象执行tail -f app.log | grep ERROR后新日志一直在刷新但终端没有任何输出过一段时间突然涌出一大段。原因grep 在输出到管道而不是终端时不再使用行缓冲改成由系统决定何时刷新内核缓冲区导致数据攒在缓冲区里没有立即显示在交互排障场景极其误导。解决给 grep 加--line-buffered强制行缓冲tail -f app.log | grep --line-buffered ERROR这个参数只影响 grep 的输出缓冲策略对匹配逻辑没有影响。在脚本里处理实时日志流时也建议带上不只是终端使用避免在计划任务里产生延迟输出。5.3 文件名带空格和通配符现象循环复制日志时for f in *.log; do cp $f /backup; done遇到my app.log这样的文件名变量$f被分词拆成my和app.logcp 报错文件被遗漏。原因shell 对未加引号的变量引用会执行单词分割文件名里的空格成为天然的分隔符。默认行为在大多数时候无害但遇到带空格的用户文件名就翻车。解决统一给变量加双引号批量操作文件名用find -print0配合xargs -0处理find /data -name *.log -print0 | xargs -0 -I {} cp {} /backup/-print0让 find 用空字符而不是换行分隔文件名xargs -0按同样的分隔符读取空格、换行、特殊字符都不用再担心。-I {}定义一个替换符花括号位置会被每个文件名逐一替换后续的cp命令中的双引号保护了目标名中的空格。相关的还有rm、mv只要是批量处理文件名统一遵循这个写法就不会出错。5.4 sudo 也改不动的文件现象root 用户用 vim 修改配置文件提示只有读权限写入失败检查属主和权限都正常。原因两种情况最容易被忽略——文件设置了 immutable 扩展属性chattr i任何写入都会被拒绝连 root 也一样或者文件所在的分区以只读方式挂载整块磁盘都无法写入。解决先用lsattr查看扩展属性再用chattr -i去掉不可修改标志用mount检查挂载参数lsattr /etc/some.conf chattr -i /etc/some.conf mount | grep ro lsattr输出的i标志就是 immutable 的迹象。chattr -i去掉后文件即可写。mount | grep ro 里的ro表示只读挂载如果命中了这一项说明是文件系统层面只读比如异常关机后系统自动以只读模式挂载这时要先确认磁盘状态再重新挂载不要强行写入。先分清是文件属性还是挂载层面的问题再决定下一步。5.5 CRLF 换行导致脚本在 Linux 上报错现象从 Windows 环境保存的脚本放到 Linux 上执行报/bin/bash^M: bad interpreter或出现$\r: command not found。原因脚本在 Windows 环境编辑保存后行尾是 CRLF\r\nLinux 只识别 LF\n\r被当成命令内容的一部分解释器路径和每一行末尾都混入了回车字符。解决用 sed 或 dos2unix 转换换行符sed -i s/\r$// script.sh # 或者 dos2unix script.shsed -i s/\r$//的原理是只删除行尾位置的\r不影响文件正文里的其他内容。dos2unix 是更专用的工具处理批量文件更方便。这个坑也可以通过编辑器的设置从源头避免文本类文件统一把换行符设为 LF不管当前系统是什么环境。习惯后这变成一条经验拿到外来脚本先跑一条file script.sh看一眼编码和换行信息再决定直接执行还是先转换。6. 把常用命令沉淀成自己的诊断习惯一个快速检查脚本前几章的命令单独看都不难但真正能提升效率的做法是把它们组合成一套自己的检查流程。我习惯在每个服务器上放一个简短的健康检查脚本里面是前面命令的组合——磁盘、内存、进程、日志一次扫完排障时先跑一遍再决定下一步往哪个方向深挖。#!/bin/bash set -u echo 磁盘使用 df -hT | grep -v tmpfs echo 内存使用 free -h | head -n 2 echo CPU 占用前 5 的进程 ps aux --sort-%cpu | head -n 6 echo 最近 20 条 ERROR 日志 tail -n 500 app.log 2/dev/null | grep ERROR | tail -n 20这个脚本把第 4 章的核心检查项集中起来set -u防止变量问题grep -v tmpfs过滤掉虚拟内存文件系统的显示避免刷屏2/dev/null保证日志文件不存在时脚本不会中断。跑出来的结果不需要全部看懂重点是快速得到四个维度的概览磁盘快满了吗、内存紧不紧张、哪个进程在吃 CPU、日志里有没有 ERROR。除了脚本我还会用 alias 固化两个最高频的命令比如alias ..cd ..和alias grepgrep --colorauto写在 shell 的 rc 文件里。别小看这两条--colorauto在高亮显示匹配内容时长日志里找错误信息一眼就能圈定范围。我之前没有把这些沉淀下来时每天排障都是东敲一条西敲一条后来在一个通宵排查的晚上猛然发现自己有一半时间浪费在重复输入相同的命令组合上。那之后我开始建脚本、加注释、把每次踩坑的解决方式写进检查清单里。现在面对一台陌生的服务器拿起这个脚本先跑一圈问题基本就浮出水面了。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助?