简介：面向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压缩解压，以及重定向、管道、通配符等符号命令的基础语法，并附带ctrl+c、ctrl+r、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 -r

type -a的优先级是别名、内建、外部命令，它能直接告诉你ls是被alias成了ls --color=auto，还是真的走了/bin/ls。which只负责在PATH里找可执行文件，如果你在某个目录下配置了PATH却忘了执行source，which自然找不到。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 -30

man -k是新手最容易忽略的入口，它能在不记得命令名的情况下按关键词搜索手册。比如你知道想查文件权限的设置方法但忘了chmod这个词，man -k permission就能把相关命令列出来。info是比man更结构化的文档，但对多数命令来说man已经足够，不必强求。我的习惯是先用--help拿最常用的参数，不够了再去man里找细节，这样既不浪费时间，也能保证参数含义不猜。

2.3 history与Ctrl+R：让敲过的命令变成可复用的资产

同一个命令隔三天再敲一遍，却怎么也想不起来当时用了什么参数，这是所有人都会遇到的事。history在交互式Shell里会自动记录命令历史，默认存到~/.bash_history，但它有几个细节：默认只在Shell正常退出时写入，如果你用kill -9把终端进程杀了，本次会话的历史可能全部丢失；多条终端同时开着时，后写出的会覆盖先写的。手动执行history -a可以强制把当前会话的命令追加到历史文件里，这是多窗口环境下的保命操作。

# 查看最近使用的20条命令 history 20 # 搜索历史中含nginx的命令 history | grep nginx # 反向搜索，输入关键字后Ctrl+R逐条回溯 # 按Ctrl+R，输入"rsync"，再按Ctrl+R继续向前找 # 把当前会话历史立即追加写入历史文件 history -a

历史记录不只是拿来翻的，更实用的用法是用Ctrl+R做反向搜索，手还没离开键位就能把上个月前用过的复杂rsync命令捞回来。配合HISTCONTROL=ignoreboth这个环境变量，可以避免记录重复命令和以空格开头的命令——后者适合用来临时执行不想留痕的命令。养成定期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/app

stat输出的信息要重点看三行：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/ user@10.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.txt

ls -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 defunct

ps -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 -30

top在交互模式下按1可以展开每个逻辑核的使用率，这是判断“单核满载还是整体烧高”的关键操作。如果总CPU不高但单核100%，说明是单线程卡住了，可能是GC频繁或者锁竞争，方向完全不同。按E可以循环切换内存显示单位，从KiB换到MiB甚至GiB，比在KB单位里数零强得多。批处理模式-bn1适合放进采集脚本，但注意要加head截断，否则top会把所有进程列表完整输出一遍。

4.3 kill -9不是第一选择：先TERM后KILL的规矩

进程卡死时许多人上来就是kill -9，这属于直接剥夺进程处理善后工作的机会。优雅的顺序是先kill（默认发TERM信号，15），让进程自己执行收尾逻辑，等几秒没反应再kill -9（KILL信号，9）强制结束。正常情况下进程会响应TERM自动退出，只有死循环或卡在内核态无法响应信号的进程才需要KILL兜底。

# 向PID 12345发送TERM信号，手工优雅停止 kill 12345 # 强制结束，仅当TERM无效时使用 kill -9 12345 # 按进程名结束：pkill避免先查PID的环节 pkill -f "uwsgi --master" # 查看所有信号名称和编号 kill -l

pkill -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 now

journalctl用--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 /data

du -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 rm='mv -t /tmp/trash'，再配一条crontab定期清理trash目录，或者只在执行危险操作前把rm习惯性替换为mv并确认路径。

5.2 管道加grep时进程自己卡住

现象：执行tail -f app.log | grep "error"后，终端既不输出也不响应Ctrl+C。原因：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问题时每一步都有明确的方向。

本文还有配套的精品资源，点击获取