★ FEATURED ARTICLE 简介面向Linux终端高频使用者、运维工程师及入门学习者这份docx文档以速查形式整理了系统常用命令覆盖文件与目录操作如cd、mkdir、cp、mv、rm、进程与系统状态查看top、ps、kill、free、df、文本内容查看与编辑cat、more、less、head、tail、wc、网络配置与连通性测试ifconfig、ping、hostname等高频场景遇到具体操作问题时可按类别快速定位。文档同时补充了chmod、chown等权限管理gzip、tar压缩解压以及重定向、管道、通配符等符号命令的基础语法并附带ctrlc、ctrlr、tab补全等常用快捷键便于理解命令组合逻辑并编写简单Shell脚本整体按操作类别分块适合作为终端日常工作的速查手册。资源为1个docx文件压缩包仅18KB轻量精简方便随时查阅。目前已有320人学习/下载适合希望减少死记硬背、按需检索命令用法的初学者和日常运维人员。1. 先弄清楚Linux常用命令到底在解决什么接手一台没有图形界面的Linux服务器最常听到的一句话是“命令背熟就行”。真到了线上环境你会发现卡住你的很少是某个命令没背过而是不知道此刻该用哪一条、参数按什么规矩给、输错了会不会造成不可逆后果。Linux常用命令与操作详解这类资料满天飞但多数只是把命令按字母排序罗列一遍真正缺的是“遇到问题时按什么顺序把命令组合起来”的思考方式。这篇笔记不打算做成命令大全而是按一线运维和开发最常碰到的几类场景——文件与目录、进程与资源、日志检索、服务管理——把命令的选型和执行顺序讲清楚。每个阶段都会给出可直接复制的最小命令集再说明参数为什么这么写、失败时应该看什么。适合刚接触Linux的入门者照着敲一遍也适合已经会一些命令但总在细节上翻车的同学对照排查。你不需要背下所有命令只需要建立一套“查手册、看反馈、用组合”的操作习惯。2. 命令怎么查、怎么记、怎么复用先把手边工具用满2.1 type、which、hash先搞清楚命令到底是哪来的很多新手遇到“command not found”第一反应是去下载安装其实更常见的是这个命令根本没在你的PATH里或者被Shell的hash缓存指向了旧路径。排查这个问题我一般会依次用三条命令确认type、which、hash。# 查看ls这个命令是内建命令、外部命令还是别名 type -a ls # 查看nginx可执行文件的路径注意which只认PATH里的 which nginx # 查看当前Shell命令哈希表确认某命令实际指向哪里 hash -t nginx hash -rtype -a的优先级是别名、内建、外部命令它能直接告诉你ls是被alias成了ls --colorauto还是真的走了/bin/ls。which只负责在PATH里找可执行文件如果你在某个目录下配置了PATH却忘了执行sourcewhich自然找不到。hash -t能看到当前Shell实际记住的命令路径当你改了某个二进制文件的位置而“旧命令还在生效”时执行hash -r清空缓存立刻就能验证。这三条命令本身不难关键是查错顺序。先type确认是不是别名或内建再which确认PATH有没有问题最后hash确认是不是缓存作祟。按这个顺序排查“命令找不到”五分钟内能定位九成问题。2.2 man、info、--help不联网也能把参数看懂断网环境下一个参数记不清了不要急着翻浏览器Linux自带的帮助系统足够解决大多数疑问。最常用的是man其次是命令自带的--help。关于man有两点容易被忽略一是man按章节分类2是系统调用3是C库函数5是配置文件格式8是系统管理命令查不到时要确认自己是否在正确的章节里二是man页里会给出EXIT STATUS和BUGS段落前者告诉你返回码0和1各自的含义后者坦白写了已知坑翻车时参考价值很高。# 查kill命令的手册区分处于第1节shell命令还是第2节系统调用 man 1 kill man 2 kill # 快速搜索与permission相关的手册页 man -k permission # 用--help看tar的常用参数比man更精简 tar --help | head -30man -k是新手最容易忽略的入口它能在不记得命令名的情况下按关键词搜索手册。比如你知道想查文件权限的设置方法但忘了chmod这个词man -k permission就能把相关命令列出来。info是比man更结构化的文档但对多数命令来说man已经足够不必强求。我的习惯是先用--help拿最常用的参数不够了再去man里找细节这样既不浪费时间也能保证参数含义不猜。2.3 history与CtrlR让敲过的命令变成可复用的资产同一个命令隔三天再敲一遍却怎么也想不起来当时用了什么参数这是所有人都会遇到的事。history在交互式Shell里会自动记录命令历史默认存到~/.bash_history但它有几个细节默认只在Shell正常退出时写入如果你用kill -9把终端进程杀了本次会话的历史可能全部丢失多条终端同时开着时后写出的会覆盖先写的。手动执行history -a可以强制把当前会话的命令追加到历史文件里这是多窗口环境下的保命操作。# 查看最近使用的20条命令 history 20 # 搜索历史中含nginx的命令 history | grep nginx # 反向搜索输入关键字后CtrlR逐条回溯 # 按CtrlR输入rsync再按CtrlR继续向前找 # 把当前会话历史立即追加写入历史文件 history -a历史记录不只是拿来翻的更实用的用法是用CtrlR做反向搜索手还没离开键位就能把上个月前用过的复杂rsync命令捞回来。配合HISTCONTROLignoreboth这个环境变量可以避免记录重复命令和以空格开头的命令——后者适合用来临时执行不想留痕的命令。养成定期history -a的习惯后你的命令历史就是一个不断积累的私有手册比任何收藏的笔记都贴近实际问题。3. 文件与目录操作ls、stat、ln、find里的四个高频细节3.1 ls -l不等于全部信息时间戳和权限要配合stat才能看全ls -l是大多数人检查文件的默认方式但它有个隐藏问题默认显示的时间是mtime内容修改时间而排查“文件为什么变了”时关键往往在ctime状态变更时间或atime访问时间。ctime改了但mtime没改的情况很常见比如有人chmod了文件权限、或者改了属主这时候ls看时间戳完全看不出异常用stat才能发现线索。# 查看完整时间戳和权限信息 stat app.log # 只看最近修改的文件按时间倒序 ls -lt /var/log/ | head # 只列出目录本身不展开目录内容 ls -ld /opt/appstat输出的信息要重点看三行Access、Modify、Change分别对应atime、mtime、ctime最容易踩的坑是ctime概念混淆。ctime不是创建时间而是inode变更时间——权限、属主、链接数一变ctime立刻更新。很多事故排查到最后才发现是某条自动化脚本定时chmod了目录靠的就是这个差异。ls -ld则解决另一个问题不加-d时ls /opt/app会列出该目录下的内容而你本来只是想知道这个目录本身的情况。3.2 cp与rsync怎么选先看你要的是“复制”还是“同步”cp负责复制rsync负责同步两者看起来都能把文件从A弄到B但适用场景差很多。单机内复制几个文件cp -a保留权限和时间戳速度最快跨机器、跨磁盘或者需要增量拷贝时rsync几乎是唯一合理选项。rsync的核心优势是可以断点续传、只传差异部分而且通过SSH传输时不需要额外开服务。# 保留权限、属主、时间戳地复制目录 cp -a /data/app /backup/app_bak # 只同步/app目录下的内容到远程服务器注意末尾斜杠的含义 rsync -avz --delete /data/app/ user10.0.0.8:/data/web/ # 模拟执行先看会传哪些文件确认无误后去掉--dry-run rsync -avz --dry-run /data/app/ /backup/app_test/rsync的斜杠是经典翻车点/data/app/带斜杠表示同步“目录里的内容”不带斜杠表示把“这个目录本身”也传过去目标路径会多出一层目录。--delete参数更要谨慎它会让目标端删除源端没有的文件适合做镜像备份但一旦源目录路径写错目标端会被清空。所以我一直坚持先跑--dry-run确认传输列表里没有意外的删除项后再正式执行。3.3 ln硬链接和软链接删除文件时两者的行为完全不同创建软链接用ln -s创建硬链接用ln这个大家都会。但两者的删除行为经常让运维在排障时困惑软链接是指针源文件删了链接就断了硬链接是同一个inode的多个目录项任何一个“文件”删了只要还有一个硬链接存在数据就还在磁盘上。这意味着对硬链接文件执行rm并不会释放磁盘空间直到所有指向该inode的链接都被删掉。# 创建软链接注意第一参数是源文件第二参数是链接名 ln -s /var/lib/mysql /data/mysql_link # 创建硬链接并查看两文件是否指向同一inode ln /tmp/note.txt /tmp/note_hard.txt ls -i /tmp/note.txt /tmp/note_hard.txtls -i输出每个文件的inode号两个文件号相同就说明是同一份数据的不同入口。这个特性在排查“磁盘空间怎么没释放”时很关键某个日志文件被程序打开着你又rm掉了文件名但进程还持有文件句柄空间照样不释放。此时用lsof L1可以找到被删除但还占着空间的文件再定位是哪个进程打开的这也是日常运维里非常经典的一招。3.4 find最容易被忽略的坑通配符要引号-exec要慎重find是Linux命令里使用门槛最高的一条新手老是发现find明明在报错或者结果不一样。绝大多数原因出在通配符上find -name .log时如果不加引号Shell会先把.log展开成当前目录下已存在的.log文件列表再把这一堆文件名送给find结果自然不是你想要的。另一个频繁踩坑的是-exec它的语法分号要转义成;很多人在这个分号上卡到怀疑人生。# 正确写法通配符用双引号包住阻止Shell提前展开 find /var/log -name *.log -type f -mtime 7 # 按大小找文件大于500MB的文件常用于排查磁盘占用 find / -xdev -size 500M 2/dev/null # 对查到的文件执行ls -lh注意-exec必须以\;结尾 find /tmp -type f -exec ls -lh {} \; # 更安全的批量操作方式把结果先导出人工确认后再处理 find /data -type f -name *.tmp /tmp/clean_list.txt-size 500M配合-xdev是个低调但实用的组合。xdev的意思是不要跨文件系统否则find会一路搜进/proc等虚拟目录把系统文件也列出来干扰判断。我还是建议把find的结果先重定向到文件里人工过目一眼再决定下一步尤其涉及删除时靠命令行直接-exec rm是翻车概率最高的操作。4. 进程、资源与日志把线上问题一步步拉出来4.1 ps与top配合先看“有没有”再看“谁在闹”排查CPU吃满、接口超时这类问题第一步不是看代码而是先看进程状态和资源占用。ps负责快照top负责动态追踪两者的使用顺序一般是先用ps确认进程还在不在、PID是多少再用top盯住它的实时占用趋势。ps aux和ps -ef结果几乎一样区别只在显示格式——aux在BSD风格下会有STAT列-ef标准风格更适合写脚本解析。# 查看所有进程的完整命令行按CPU使用率排序 ps -eo pid,ppid,user,cmd,%cpu,%mem --sort-%cpu | head -20 # 精确查找包含nginx的所有进程注意加grep排除自身 ps -ef | grep nginx | grep -v grep # 实时查看进程树处理僵尸进程排查时这个最直观 pstree -ap | grep defunctps -eo自定义输出列是个容易忽略但非常实用的姿势它能把你要的信息压缩成一行再用--sort按CPU或内存排序。查找某个进程时grep -v grep是经典细节少了这步你会看到一个grep自己匹配出来的结果。僵尸进程用ps -ef看到的是PID后带defunct的条目配合pstree能看到它的父进程是谁然后去查父进程为什么没有正确调用wait回收子进程。4.2 top的交互模式和负载均值怎么读top一进去看到LOAD AVERAGE一串三个数字很多人的第一反应是问“这个值多少算高”。三个数字分别对应1分钟、5分钟、15分钟的平均负载不是“百分比”而是“正在运行和等待运行的进程平均数”。判断是否过载要结合CPU核数8核的机器负载跑到8不一定有问题而双核机器负载到6就明显过载了重点看趋势而不是单个数值。# 进入top后按P按CPU排序按M按内存排序 top # 只监控指定PID适合盯住单个异常进程 top -p 12345 # 批处理模式输出一次结果供脚本采集后退出 top -bn1 | head -30top在交互模式下按1可以展开每个逻辑核的使用率这是判断“单核满载还是整体烧高”的关键操作。如果总CPU不高但单核100%说明是单线程卡住了可能是GC频繁或者锁竞争方向完全不同。按E可以循环切换内存显示单位从KiB换到MiB甚至GiB比在KB单位里数零强得多。批处理模式-bn1适合放进采集脚本但注意要加head截断否则top会把所有进程列表完整输出一遍。4.3 kill -9不是第一选择先TERM后KILL的规矩进程卡死时许多人上来就是kill -9这属于直接剥夺进程处理善后工作的机会。优雅的顺序是先kill默认发TERM信号15让进程自己执行收尾逻辑等几秒没反应再kill -9KILL信号9强制结束。正常情况下进程会响应TERM自动退出只有死循环或卡在内核态无法响应信号的进程才需要KILL兜底。# 向PID 12345发送TERM信号手工优雅停止 kill 12345 # 强制结束仅当TERM无效时使用 kill -9 12345 # 按进程名结束pkill避免先查PID的环节 pkill -f uwsgi --master # 查看所有信号名称和编号 kill -lpkill -f是按完整命令行匹配比pkill按进程名匹配更保险但也更容易误伤——只要命令行里含有关键字就会被杀所以使用前先用pgrep -f确认匹配范围是必要的。用kill -l能看到TERM是15、KILL是9这些编号切记不要用kill -9当默认操作尤其对数据库或队列进程宁可多等几秒也不要造成数据异常。4.4 systemctl与journalctl服务状态和日志要对着看systemd时代排查服务问题多数时候不看传统日志文件而是用systemctl查状态、用journalctl拉日志两个命令配合能覆盖从“服务为什么没起来”到“启动后为什么又崩了”的全过程。systemctl status的输出里有几个关键字段ActiveState是服务当前状态MainPID是主进程号最底部会直接给出最近几条日志许多问题不用跳转就能定位。# 查看服务运行状态和最后几条日志 systemctl status nginx # 只看最近30分钟内的服务日志单位可以是minutes/hours/days journalctl -u nginx --since 30 minutes ago # 滚动跟踪日志输出联调时保持终端常开 journalctl -u nginx -f # 查看上次启动后的全部日志排查“重启后立刻崩溃” journalctl -u nginx --since today --until nowjournalctl用--since和--until指定时间窗口这个时间窗口写法非常灵活支持10 minutes ago、yesterday、2024-06-01 12:00:00等格式。日志量大的环境下直接journalctl -u nginx不设时间范围会把输出刷到怀疑人生所以带上时间窗口几户是必须习惯。配合-f滚动模式时先开一个终端跟踪日志再在另一个终端执行重启操作服务崩溃瞬间的报错信息就不会被淹没在启动日志里。4.5 df与du在排查磁盘占用时的分工磁盘告警是所有运维都会遇到的日常df和du看似都是看磁盘实际上分工很清楚df看文件系统级别的空间占用du看目录树的文件累计大小。判断“磁盘满没满”以df为准定位“空间被谁占了”用du。但du和df数字对不上是经常发生的事一个常见原因是文件被删除但被进程占用另一个是目录挂载点跨了文件系统。# 查看所有挂载点的使用率注意- h用易读格式 df -h # 查看inode使用率小文件过多时空间没满但inode耗尽 df -i # 统计当前目录下每个一级目录占用是排查磁盘空间的起手式 du -xhd1 /datadu -xhd1这一串参数每个都别少x表示不跨文件系统避免把挂载的其他磁盘也统计进来h用易读单位d1只统计当前目录下的一级子目录。执行完你能立刻看到是哪个目录占了大头然后一路cd进去继续用du逐层追查。很多“磁盘满了但du看起来不大”的情况真正原因就是前文提到的已删除但被进程持有的文件这时df显示满而du各目录加起来远小于总量需要用lsof L1去找罪魁祸首。5. Linux命令避坑五个让你翻车的高频点5.1 rm误删后才发现没备份习惯性用mv代替rm现象本来想删/tmp下的临时文件结果通配符写错删掉了一整个项目目录下的生产配置。原因rm不经过回收站-rf连确认提示都省了一旦误删没有任何后悔药。解决在关键目录下把rm换成mv到/tmp/trash目录相当于手动实现一个回收站机制。具体的做法是在.bashrc里定义alias rmmv -t /tmp/trash再配一条crontab定期清理trash目录或者只在执行危险操作前把rm习惯性替换为mv并确认路径。5.2 管道加grep时进程自己卡住现象执行tail -f app.log | grep error后终端既不输出也不响应CtrlC。原因tail -f是持续跟踪管道后grep默认行缓冲两者组合起来会因为缓冲区不刷出导致看起来死掉。解决grep加上--line-buffered参数强制逐行刷新输出或者用tail -f配合grep -F精确匹配关键字减少误报。另外这条命令杀不掉时用Ctrl\或另开终端查PID再kill不要一直盲等。5.3 find加-exec处理大量文件时提示参数过长现象find /data -name *.log -exec rm {} ; 执行到一半报Argument list too long。原因-exec对每个文件都会启动一个新进程文件数量稍大时系统参数列表上限被击穿。解决改用find ... -delete直接删除或用xargs分批次处理xargs默认会让你控制每批数量避免一次性把所有文件路径塞给rm。更稳妥的方式是先find输出到文件再确认无误后执行xargs rm。5.4 命令提示Permission denied但用户明明在sudo组现象sudo执行命令报“不在sudoers文件中”。原因sudo -s和su -的差异被忽略了sudo -s只是切换到shell后续命令仍受sudoers规则约束另外有些系统用sudo -i才能正确加载root环境变量。解决先确认当前用户在wheel或sudo组里然后sudo visudo检查规则是否覆盖了该组不要为了图省事去改/etc/sudoers文件权限。5.5 内核OOM杀掉了自己服务而不是别人现象没排查就重启服务结果过几分钟又被杀掉dmesg里出现Out of memory。原因Linux的OOM Killer会优先杀占用内存高的进程如果你的服务本身内存有泄漏或者没做cgroup限制它就是最高优先级目标。解决加内存限额给systemd服务设置MemoryMax配合日志的OOM记录逆向攻关代码问题。排查时用dmesg | grep -i oom查看内核淘汰记录不要一上来就怀疑别人杀了进程。6. 把常用命令串成一条实战链路一块磁盘满的完整排查以“系统提示No space left on device”为例用上面所有命令串成一个可复现的排查顺序。先确认空间真的满了吗还是inode耗尽了df -h看容量df -i看inode五秒内分清两个方向。接着用du逐层定位大文件du -xhd1 /然后逐级深入找到占空间最大的目录。如果df显示满但du加起来差很多用lsof L1找出被删除但还握着文件句柄的进程这条命令的输出会直接给出进程PID和文件路径之后去检查对应进程为何不释放句柄这是大部分“空间神秘消失”的根源。# 第1步同时确认空间和inode情况 df -h df -i # 第2步定位大目录从根开始逐层深入 du -xhd1 / 2/dev/null | sort -rh | head -10 # 第3步按文件大小找大文件同时排除系统虚拟文件系统干扰 find / -xdev -size 200M -type f -exec ls -lh {} \; 2/dev/null # 第4步查找被删除但未释放空间的文件 lsof L1 | head -20这个顺序的顺序价值在于每一步都有明确的下一步判断依据df -i使用率特别高时直接跳到第2步的“找小文件数量多”方向du输出里某个目录明显异常时继续深入它lsof无输出则说明磁盘空间确实被正常文件占着不存在隐藏占位。整套排查下来从接到告警到定位到具体文件熟练后不会超过一刻钟。我自己的习惯是每次执行完第4步都会顺手把lsof的输出重定向保存一份作为后续基线数据。避免内存等资源被进程撑爆的关键不仅仅看单个命令的结果更要关注多个命令输出之间的相互印证——比如df和du矛盾、lsof出现但服务还在新增日志说明有进程处于异常状态需要处理而不是单纯清文件。希望这个思路能帮你少走一些弯路也祝你在排查Linux问题时每一步都有明确的方向。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
