刚接触 Linux 的时候，我也找过一份所谓“Linux 常见命令集合”，复制到笔记里当作字典来背。结果可想而知：背了三天，连文件权限数字对应的含义都记不牢。后来在实际项目里摸爬滚打，才慢慢明白，命令不是背出来的，而是在一次次真实的文件操作、日志排查、服务部署里用出来的。
这篇内容我不按字母表顺序罗列命令，而是按日常操作的顺序来组织：先处理文件和目录，再处理文本，然后是权限、进程、磁盘、网络。每一条都尽量说清楚“为什么这么用”，也会写一些我在生产环境里踩过的坑。这份集合会持续更新，不一定覆盖所有命令，但凡是写进来的，都是在真实环境里验证过、真正高频的用法。适合刚入行的运维、后端开发、测试，也适合把 Linux 当作日常工具的朋友。
1. 文件和目录操作：日常使用频率最高的命令主干
1.1 pwd、cd、ls 的隐藏用法
pwd用来确认当前所在目录。这个命令看起来简单，但经常被人忽略。比如你写了一个脚本，脚本里用相对路径操作文件，结果换了个目录执行就找不到文件了，这时候先跑一下pwd，往往就能定位问题。
cd -是我个人非常推荐的一个技巧，它的作用是回到上一次所在的目录。用熟了之后，在两个目录之间来回切换会非常顺手。cd ~直接回到当前用户的家目录，cd ..回到上一级，这些都属于基本功，但很多人会忽略cd -，所以单独提一下。
ls的常用参数里，-l是长格式输出，-a显示隐藏文件，-h让文件大小以易读的 K、M、G 显示。实际工作中我几乎固定使用ls -lht，它按时间倒序排列文件，最新的文件出现在最下面，配合tail查看日志时非常直观。如果嫌敲起来麻烦，可以在配置文件里加上一行别名：alias ll='ls -lht'。
你还需要区分绝对路径和相对路径。绝对路径以/开头，比如/var/log/nginx/access.log；相对路径基于当前目录，比如./logs或../conf。在脚本里写路径时，我的习惯是优先用绝对路径，避免脚本执行位置不同导致意外结果。这不是什么高深道理，纯粹是少踩坑。
1.2 复制、移动、删除：cp、mv、rm 的安全操作
cp复制文件，cp -r复制目录。生产环境里我更习惯用cp -a，它会在复制时保留权限、时间戳等属性。对于配置文件备份来说，cp -a比cp更稳，因为很多程序对配置文件权限有要求，复制完再手动改权限很麻烦。
mv有两个容易忽略的细节。第一，在同一个文件系统内移动文件，本质上只是修改路径记录，速度很快；跨文件系统移动时，操作系统会先把文件复制过去再删除原文件，耗时取决于文件大小。所以移动大文件之前，最好确认源目录和目标目录在同一块磁盘上。第二，mv默认覆盖同名文件，推荐加上-i参数，在覆盖之前先询问，避免把一个刚生成的产出文件覆盖掉。
rm是整个 Linux 里最需要警惕的命令之一。rm -rf一旦路径写错，代价非常大。我见过有人把变量没拼好，最后删掉了别的目录。日常操作几个建议：
- 删除之前先
ls确认一下路径，不要凭记忆。 - 给
rm设置别名rm -i，让系统强制确认。 - 重要数据定期备份，不要幻想误删之后还能轻松找回。
在看不清后果的情况下，宁可使用mv file /tmp/把文件挪到一个临时目录，观察一段时间，确认没问题再真正删除。
1.3 查看文件内容：cat、less、tail、head 的分工
cat适合看小文件，直接把内容全部输出。大日志文件用cat会把整个终端刷满，而且显示不全。这时候用less，它支持分页浏览，按空格键翻页，按/搜索关键字，按q退出。检查配置文件或代码时，用less明显比cat高效。
tail -f是看日志的利器，它可以持续跟踪文件新增内容。部署完服务后，开一个窗口跑tail -f /var/log/app.log，日志会一行行刷出来，哪一步报错马上能看到。tail -n 200可以看最后 200 行，head -n 50看前面 50 行。
这里有一个我自己踩过的小坑：tail -f配合管道过滤日志时，比如tail -f app.log | grep ERROR，输出会出现在缓冲区里，不会实时刷新。解决办法是给grep加--line-buffered参数，强制它逐行输出，这样过滤后的日志才能实时看到。类似的坑还有不少，建议遇到管道没有实时输出时，先怀疑缓冲。
2. 文本处理三件套：grep、sed、awk 的实际用法
2.1 grep：从日志里捞你想要的
grep是最常用的文本筛选命令。基本形态是grep pattern file，它会输出包含匹配内容的行。几个参数非常重要：
-i：忽略大小写，排查关键字时省得反复试大小写。-v：反向匹配，输出不包含该模式的行。用来看“排除无用日志”很好用。-n：显示行号，方便定位代码或日志位置。-r：递归搜索目录，适合在项目代码里找某个函数或配置。-E：使用扩展正则表达式，可以写grep -E "error|fail"这样的多个条件。
grep的返回值在脚本里很有用。匹配到内容时返回 0，没有匹配返回 1，出错返回 2。可以写类似这样的判断：
if grep -q "ERROR" /var/log/app.log; then echo "发现 ERROR 日志" fi-q表示静默模式，不输出内容，只返回退出状态，在脚本里比较常用。
2.2 sed：常用的替换和行操作
sed是流编辑器，按行处理文本。最常用的是替换操作：
sed 's/old/new/g' file.txts是替换命令，old是被替换的内容，new是替换后的内容，g表示全局替换，不加的话只替换每一行的第一处匹配。如果只想看替换结果而不真正修改文件，可以不加-i，直接把标准输出打到屏幕上；确认无误后再加上-i，表示就地修改。
sed -i建议做好备份。我一般会写成sed -i.bak 's/old/new/g' file.txt，这样会生成一个file.txt.bak备份文件，万一换错了还能回滚。批量替换配置文件时，最稳妥的流程是先复制一份到临时目录，在临时文件上测试，确认结果再回写正式文件。
sed还可以按行范围处理。比如sed -n '20,30p' file.txt只打印第 20 到 30 行，sed '50d' file.txt删除第 50 行。写脚本时，sed是批量处理文本的重要工具，但不要用它处理二进制文件，一旦改坏就很难恢复。
2.3 awk：列提取和简单统计
awk最大的价值在于按列处理文本，默认以空格或制表符作为分隔符。最简单的用法：
awk '{print $1}' file.txt这会输出每一行的第一列。$0表示整行，NF表示当前行的字段数量，NR表示当前处理的行号。
实际工作中，df -h的输出可以用awk抓取某个分区的使用率，ps aux的输出可以用awk挑出 CPU 占用最高的进程。比如：
ps aux | awk '$3 > 80 {print $2, $3, $11}'这段命令打印 CPU 占比超过 80% 的进程 ID、CPU 占比和命令名称。如果输出列和预想不一致，可能是分隔符问题。此时可以用-F指定分隔符，比如/etc/passwd按冒号划分：
awk -F: '{print $1}' /etc/passwdawk与grep的分工不同：grep擅长找行，awk擅长处理列。遇到需要提取某列做判断的场景，用awk会比grep加cut的组合更直观、更强大。不过别一开始就想着写复杂的 awk 脚本，先用简单的列提取和条件过滤，等熟悉了再深入。
3. 权限与进程管理：新手最容易踩坑的区域
3.1 权限位与 chmod、chown 的解读
Linux 里每个文件都有一套权限设置。ls -l输出的第一列类似-rw-r--r--，第一个字符表示文件类型，-是普通文件，d是目录，l是软链接。后面九个字符分三组，分别是文件所有者、所属组、其他人的读、写、执行权限。
r是读，w是写，x是执行。数字模式更常用：r是 4，w是 2，x是 1。常见组合：
| 权限 | 数字 | 含义 |
|---|---|---|
| rwx | 7 | 读、写、执行 |
| r-x | 5 | 读、执行 |
| r-- | 4 | 只读 |
| rw- | 6 | 读、写 |
执行chmod 755 script.sh，意思是文件所有者具备全部权限，组与其他用户只有读和执行权限。目录的执行权限含义要特别留意：对目录来说，x决定你能否进入这个目录，r决定你能否列出目录里的文件名。只给读取权限而没给执行权限，你会碰到看得到名字却进不去的情况，容易让人困惑。
chown用于修改文件所有者和所属组。chown user:group file表示同时修改所有者和组，chown -R user:group dir表示递归修改目录下所有内容。Nginx 或应用服务读取文件时，经常出现权限不足的报错，本质上就是运行用户对文件没有读取或执行权限，用ls -l检查所有者，再用chown调对即可。
3.2 用户与提权：su、sudo、useradd
在 Linux 下，我强烈建议不要长期用 root 操作。原因很简单：root 权限下rm没有任何确认门槛，误操作的概率虽然低，但一旦发生就很麻烦。日常使用普通用户，需要管理员权限时再临时提权，是一种更稳妥的习惯。
su -会切换用户，同时加载目标用户的环境变量。不加-时，只是切换了用户身份，但当前环境变量还是原来那个用户的。如果发现切换后命令找不到，比如java、node提示 command not found，先想想是不是少了-。
sudo是执行单条管理员命令的方式。sudo cat /etc/sudoers里可以配置哪些用户有 sudo 权限。注意，编辑 sudoers 一定要用visudo，它会检查语法，避免因为语法错误导致所有 sudo 都不可用。建议只给需要的用户分配必要的权限，不要整个组全部放开成无密码 sudo。
useradd创建用户，useradd -m -s /bin/bash username会创建家目录并指定默认 shell。创建完用户后务必设置密码，否则这个用户无法登录。生产环境里给服务单独建用户运行，能避免互相影响文件权限，是值得坚持的习惯。
3.3 进程排查：ps、top、kill 的组合拳
排查服务器问题时，ps和top是跑不掉的两个命令。ps aux会列出所有进程，其中%CPU表示 CPU 占用，%MEM表示内存占用，TIME表示进程累计消耗的 CPU 时间。配合awk可以很轻易找到占用最高的进程。
top是动态查看系统状态的工具。第一行有当前时间、系统运行时长、登录用户数、负载平均值；第二行是进程总数和运行、休眠进程数；第三、四行是 CPU 和内存使用情况。负载平均值有三个数，分别对应过去 1 分钟、5 分钟、15 分钟的平均负载。这个数是和 CPU 核心数对比看的，不是说超过 1 就是有问题，比如 8 核机器负载 4 并不算高。
kill命令默认发送TERM信号，要求进程主动退出。如果进程不响应，再考虑kill -9强制结束。实践中的顺序是先用kill PID，等待几秒，没有退出的再用kill -9 PID。直接kill -9会让进程来不及清理临时文件和释放资源，数据库或缓存服务尤其需要注意，很可能造成数据不一致。
还有一个实用的变体：pkill按进程名结束。比如pkill nginx会结束所有名称为 nginx 的进程。但它会把符合条件的所有进程都杀掉，使用前先pgrep -l nginx确认匹配范围。
4. 磁盘与系统状态：遇到问题先看哪几个指标
4.1 磁盘空间与 inode：df、du 的配合
排查磁盘问题的第一步永远是看整体空间。df -h以易读格式显示挂载点、总大小、已用空间、可用空间和使用率。当某个目录写入报错提示“No space left on device”时，先用df -h确认是不是分区满了。
有一个容易忽视的点：磁盘空间没满但同样报写满错误，多半是 inode 耗尽了。df -i可以看到每个文件系统的 inode 总数、已用数量和使用率。inode 可以理解为文件索引节点，每个文件或目录都需要占用一个 inode。当服务器上散落了海量小文件时，常见的就是这种 inode 耗尽的场景。我遇到过测试环境里一次性生成了几十万个临时文件，磁盘还剩很多空间，但 inode 用到了 100%，任何新文件都写不进去。清理了一批无用文件后，问题立刻缓解。
du用于查看目录占用空间。du -sh /var/log可以快速看到整个目录的大小，du -sh *可以列出当前目录下各项的占用。排查哪个目录把磁盘吃满时，从/开始一层层用du -sh往下缩小范围，比靠感觉猜测高效得多。
还有一个常见清理对象是/var/log，日志文件默认可能越积越大。如果确认对应日志不再需要，可以cat /dev/null > /var/log/xxx.log清空文件内容，而不是直接rm文件。因为服务进程可能仍然持有这个文件的句柄，直接删除文件后空间不会立即释放，反而会造成“磁盘看着满了但找不到大文件”的错觉。
4.2 内存与负载：free、uptime 的解读
free -h查看内存使用情况，输出的第一行是物理内存总量、已用、空闲、共享内存、缓存。第二行是 swap 使用情况。很多人看到 used 很高就紧张，其实 Linux 会尽量把空闲内存用作缓存来提高读写性能。判断内存是否真正紧张，更应关注的指标是available，它表示可被新程序使用的内存大小，包含了可以回收的缓存部分。
当 swap 使用量持续增长时，说明物理内存可能不够用了，系统开始把内存数据换到磁盘。接着观察top里KiB Swap的变化，如果持续增长，就该考虑加内存或排查进程内存泄漏。内存泄漏是长期运行服务常见的问题，表现为内存占用随时间缓慢上升，而业务流量并没有明显增长。
uptime除了显示系统运行时间，还会给出负载平均值。理解负载需要结合 CPU 核数。简单来说，每个任务需要占用一个核来处理，负载均值略大于 CPU 核数时，说明系统一直有排队等待的任务，意味着 CPU 已经处于繁忙状态。如果负载长期远超核数，先看top找是哪些进程在啃 CPU，再决定是做优化还是扩容。
4.3 系统日志：排查问题的现场记录
日志是排查问题的第一现场。不同的系统发行版日志位置会略有差异，常见的日志文件包括系统公共日志和内核日志。内核相关日志可以用dmesg查看，比如磁盘错误、内存问题、硬件识别这类底层信息，很多和系统稳定性相关的线索都在这里。
使用 systemd 的系统中，journalctl是查看服务日志的主要工具。journalctl -u 服务名可以查看某个服务的日志，journalctl -u 服务名 -f可以实时跟踪这个服务的最新输出。配合时间过滤，比如journalctl --since "10 minutes ago"，可以迅速把排查范围缩短到故障发生前后的日志。
排查一个服务为什么起不来时，我固定会按这个顺序看：先看服务状态，再看服务最近日志，最后检查语法或配置文件权限。日志里出现Permission denied，多半就是上一节说的权限问题；出现Address already in use，通常是端口被其他进程占用，用下一节会提到的ss查一下端口就知道是谁占的。
5. 网络排查与远程操作：不会出错的检查顺序
5.1 ping、ss、curl：三层由内到外的排查链路
网络出问题时，我习惯按“从底层到应用”的顺序排查。第一步是ping，判断目标机器是否可达、延迟怎么样。ping走的是 ICMP 协议，如果目标禁用了 ICMP，ping 不通也不代表服务不可用，这一点要清楚。
第二步是查端口。ss -tlnp可以列出当前服务器上监听的 TCP 端口，非常实用。-t是 TCP，-l是监听状态，-n是不做域名解析，-p显示对应进程。以前常用netstat -tlnp，现在大多数环境用ss就够，输出更简洁。查看某个端口是否有进程监听：
ss -tlnp | grep 8080如果端口在监听但访问不通，第三步用curl测试本机访问是否正常。curl -I只取响应头，适合快速判断服务是否在响应。如果在服务器本机用curl能正常返回，但外部访问不了，问题基本在防火墙或安全组规则上。
排查时还可以用telnet或nc测试远程端口是否可达，我只把它当作快速探测工具，并不会长期依赖。完整的链路是：外部访问不通 → 服务器本机curl验证服务 → 本机没有监听就查服务进程和日志 → 本机正常就查防火墙和路由。
5.2 scp 与 rsync：文件传输的两种场景
需要在两台机器之间传文件时，scp是最直接的办法：
scp local.txt user@remote:/path/to/save/ scp user@remote:/path/to/remote.txt ./它基于 SSH 加密传输，简单可靠。传单个小文件用它没任何问题。但如果要同步一个目录，或需要增量同步，rsync明显更合适。
rsync的核心优势是增量同步，对已传输过的文件做对比，只传有变化的部分。常用形式：
rsync -av --delete /source/ user@remote:/target/-a是归档模式，保留权限和时间戳，也递归处理目录；-v显示详细输出；--delete表示删除目标端多余的文件，让目标目录完全对齐源目录。这个参数需要谨慎，如果你只是备份数据，不需要严格同步，尽量别加--delete，避免误删目标端已有的文件。
大目录首次同步时间会比较长，中途中断后重新执行rsync，它会自动跳过已经同步完的部分，这是scp很难替代的优点。传输大量日志或静态资源时，我一律用rsync，只有在快速传一个小配置文件的场景才用scp。
5.3 find 与 locate：定位文件的习惯
找文件的需求主要分两类：按名字找、按属性找。find功能最全面，但速度取决于扫描范围。最基本的用法：
find /etc -name "*.conf"-name按文件名匹配，-type f只看普通文件，-type d只看目录，-mtime -1表示最近一天内修改过的文件。排错时，用-mtime找最近变化的文件往往很有效。
find支持执行命令，比如把查到的文件批量打包或删除。我建议对find的-exec和-delete保持高度谨慎，旧日志清理这样的操作先加-print查看结果，确认没问题再真正执行。
locate依靠预建索引查询，速度很快，但它查不到刚创建的新文件，因为索引不是实时的。系统里如果没安装或索引过期，可以先执行updatedb再查。习惯了find之后，大部分场景我不会单独安装locate，除非在只读场景下需要快速查一个已知文件名。
6. 建立自己的命令记录习惯：比背命令更重要的几件事
6.1 history 与 alias：让常用操作更顺手
history命令可以查看当前会话的历史命令。当你忘了某条命令是怎么写的时候，先history | grep 关键字搜一下历史记录，通常能找到答案。按Ctrl+R进入反向搜索也是我平时的高频操作，输入关键字，自动匹配历史记录，回车即可补全。
alias可以为常用命令设置别名。我个人的.bashrc里维护了一小批别名，例如alias ll='ls -lht'、alias rm='rm -i'，每次新建用户都会顺手把这些写进去。这些别名会极大降低误删概率，也是新手过渡期的安全网。
但是别名也别设得太花哨。不要为了追求“一条命令完成所有事情”而堆砌复杂的链式命令。别人接手你的机器时，看到一串莫名其妙的别名会很难受。保持简单，贴近系统默认习惯。
6.2 man、--help、tldr：命令查不到时怎么办
没有谁能记住所有命令的参数。遇到不熟悉的命令，先用命令 --help看简洁参数说明。如果不够，再看man 命令，它是完整的参考手册，里面包含了用途、参数、示例、退出状态等大量信息。man打开后按/搜索关键字，按q退出。
如果man内容太长看不进去，可以尝试tldr这类工具，它把常用命令总结成极简示例，非常照顾记忆负担，适合快速回忆用法，而不是取代 man。
养成查文档的习惯，比背命令重要得多。一个合格的排查过程不是靠背下来的参数硬凑，而是能快速在手册里定位到正确的选项。我记得第一次接触 rsync 的--delete时就是在 man 里确认了它的副作用，才避免了数据损失的风险。
6.3 持续更新的意义
这份命令集合之所以强调“持续更新”，是因为 Linux 命令虽然基础稳定，但用法场景会不断变化。我自己会记录每次项目里遇到的新问题、新命令和当时的解决思路，一段时间后整理成笔记。翻一翻以前踩过的坑，往往能避免同样的错误发生第二次。
日常维护笔记时，我会按照“场景 → 命令 → 为什么用”的方式记录，而不是单纯记录命令本身。比如记录日志清理时，不写“某命令可以清日志”，而是写“磁盘满 → 先 df -h 定位 → 再 du -sh 排查 → 用重定向清空日志文件”。这样在真实故障发生时，翻到这条记录，能顺着思路快速排查。
每个 Linux 使用者的成长路径不一样，但有一点是共通的：命令收集只是起点，把它放进自己的工作场景里不断验证、调整，才能真正发挥作用。也欢迎你在这篇内容的基础上，添加自己的实战用法，这样这份集合才真正属于你自己。
