企业官网建设流程全解析

Linux 常用命令实战：一条命令一条坑，我把踩过的坑都写在这里

刚接触 Linux 的同学，八成都有过这种体验：买了一本几百页的命令大全，背了几十条参数，打开终端还是不知道该敲什么。这不是你的问题，是学习路径错了。命令从来不是靠背的，是靠用的。我做了多年运维，每天泡在终端里的时间比在浏览器里还多，说实话常用的命令翻来覆去也就那几十条。这篇博文就围绕 "Linux 常用命令" 这个主题，把我日常工作中真正高频使用的命令、参数和踩过的坑整理出来，不讲大而全的字典，只讲那些你打开终端就立刻用得上、出了问题能救命的东西。适合刚转行做运维、正在学 Linux 基础、或者已经用了一段时间但想查漏补缺的朋友。

1. 先把思路理清楚：别背命令，按场景去记

1.1 为什么你总是记不住命令

很多人学命令的方式是把ls、cd、cp、mv、rm一个个抄在本子上，旁边标注"列出文件""切换目录""复制文件"。背完前三页就放弃了，因为你会发现ls的参数十几个，cp的参数也十几个，全背下来根本不可能，而且背了不用很快就忘了。

正确的做法是反过来：先明确你要解决什么问题，然后去找解决问题的那条命令。比如"我想看这个目录占了多少磁盘空间"，对应的命令就是du -sh；"我想找到昨天改过的配置文件"，对应的命令是find /etc -mtime -1。命令是工具，不是知识。你不需要记住螺丝刀的所有型号，只需要知道"拧螺丝要用螺丝刀"这个事实，用到的时候自然就会去查。

所以下面所有内容，我都按照"你打开终端想干什么"来组织，而不是按照命令字母表排序。这也是这篇博文和其他命令大全最大的区别。

1.2 高频场景大盘点：日常工作其实就这几类

我在实际工作中，发现 Linux 命令的使用场景翻来覆去就是这六类：

第一类，文件与目录操作。不管你是部署项目还是排查日志，第一步永远是"找到文件、看清文件、搬动文件"。

第二类，文本处理。日志分析、配置修改、批量替换，全是文本活。Linux 的哲学是"一切皆文件"，文件里装的就是文本。

第三类，进程与系统状态。服务器卡了、CPU 飙了、内存不够了，都要靠这一类命令定位问题。

第四类，权限管理。多用户环境下，谁能不能读哪个文件，哪个脚本能不能执行，权限搞不定，履带装上炮塔也开不动。

第五类，网络排查。连不上服务、端口被占、域名解析失败，这类命令能帮你快速圈定问题范围。

第六类，软件安装与日志查看。新环境搭建、服务异常排查，都离不开这两个动作。

接下来每一节，我挑这类场景里最核心的命令讲透，包括参数怎么选、输出怎么看、坑在哪里，都是基于我个人实战经验的总结。

2. 文件与目录操作：这些命令每天用，但细节坑最多

2.1 ls 只看大小和名字？你错过了好多信息

ls -lh

-l是长格式输出，-h是人性化显示文件大小。这两参数基本是绑定组合，我几乎没见过只敲ls不加-lh的老手。输出你会看到类似这样的内容：

-rw-r--r-- 1 root root 12K Aug 10 14:23 app.log drwxr-xr-x 2 root root 4.0K Aug 10 14:20 conf

第一列-rw-r--r--是权限位，这行信息里除了文件名和大小，还藏着文件类型、权限、属主属组、最后修改时间。看日志文件时我习惯加-lt，按修改时间倒序排列，最新改动的文件排在最上面，排查问题时非常有用。

2.2 cd 不只是切换目录，这两个用法要刻进脑子里

cd - cd ~

cd -是回到上一次所在的目录，这个命令在"配置文件和日志文件在两个目录之间来回切换"时太好用了，省下来的时间够你多喝两口水。cd ~是回到当前用户的家目录，放脚本、找配置都从这里开始。

新手最容易犯的错是混淆相对路径和绝对路径。绝对路径从根/开始写，比如/etc/nginx/nginx.conf，不管你在哪个目录都能定位到。相对路径是相对于当前位置的，./表示当前目录，../表示上一级目录。我见过新人在/etc/nginx/目录下执行vim /etc/nginx/nginx.conf结果打开了一个新文件，就是因为多写了一个开头斜杠或者拼错路径，所以养成"用pwd确认当前位置"的习惯很重要。

2.3 cp、mv、rm：破坏性操作的三道保险

先看cp复制文件：

cp -a source_dir target_dir

-a等于-dR，保留所有属性并递归复制。复制整个目录时，不加-a会丢失软链接、权限时间戳等属性，部署项目时很容易踩这个坑。

再看mv移动或重命名文件：

mv old_name new_name

mv是"先复制再删除"的简化版，所以跨文件系统移动大文件时可能耗时较久，这是正常现象。如果把目录移动到已存在的目录里，它会被放进那个目录内部；移动到不存在的路径，则相当于重命名。这个细节容易让人困惑，我先说明白。

最危险的是rm：

rm -rf directory/

-r递归删除目录，-f强制不提示。这个组合是所有运维的噩梦。我在生产环境上删除目录时，永远先执行ls -la看清楚目录里是什么，然后再用rm -rf。更稳妥的做法是先把要删的东西mv到一个临时目录，确认没问题后再清掉。这条建议是我踩过坑之后总结的，价值远超任何命令参数。

提示：rm -rf /会删除根目录下所有文件，这是不可逆操作，执行前一定要确认路径。我个人的习惯是绝对路径手打一遍，不用 Tab 补全，强制自己确认一次。

2.4 find：找文件的高阶用法，配合通配符威力翻倍

find /var/log -name "*.log" -mtime -7

这条命令在/var/log下找 7 天内修改过的所有.log文件，排查近期异常最常用。-mtime -7表示修改时间在 7 天内，+7表示 7 天前。如果要按文件大小找，用-size +100M找出超过 100MB 的大文件，磁盘告警时第一条命令就是它。

find还可以直接执行操作：

find . -name "*.tmp" -delete

删除当前目录下所有.tmp后缀的临时文件。注意-delete也是直接删除，没有回收站，建议先用不带-delete的版本跑一遍，确认输出列表没问题再删。

3. 文本处理三剑客：grep、sed、awk 的日常实战

3.1 grep 过滤日志：从大海捞针到精准定位

grep "ERROR" app.log

这是最简单的用法，从日志里筛错误。实际工作中我几乎不用裸grep，必加参数：

grep -n "ERROR" app.log

-n显示行号，定位到具体出错位置。如果你要同时看匹配行的上下文，用-C 5，显示前后 5 行。排查 Nginx 错误日志时，我会用：

grep -n -C 3 "connection refused" error.log

这样不仅能看到报错本身，还能看到报错前后的请求信息和环境上下文。日志分析这件事，最容易犯的错是只盯着报错行看，忽略了上下文，很多时候真正的原因是报错之前的资源耗尽或超时。

grep还支持正则，比如找出所有 IP 地址：

grep -oE "[0-9]{1,3}(\.[0-9]{1,3}){3}" app.log | sort | uniq -c

-oE只输出匹配的部分并启用扩展正则，后面接sort排序再uniq -c统计次数，一条命令就能算出哪些 IP 访问最频繁。日常流量排查时这个组合很实用。

3.2 sed 替换文本：批量改配置的最佳工具

sed -i 's/old_text/new_text/g' config.conf

把config.conf里所有old_text替换成new_text。-i是直接修改文件，g是全局替换每一行所有匹配项。不加g的话，每行只替换第一个匹配，这个细节容易被忽略。

我批量修改多台服务器的配置文件时，常用这种组合：

sed -i 's/192.168.1.10/192.168.1.20/g' /app/config/*.properties

*通配符配合sed，一条命令搞定几十个文件的批量替换。注意-i在不同 Linux 发行版下的行为有细微差别，某些版本要求-i后面必须跟后缀参数。更稳妥的做法是先去掉-i跑一遍，用输出确认替换结果无误后再加上-i真正落地。这也是"先验证后执行"原则的体现。

3.3 awk 按列处理：日志分析的隐藏神器

awk最常用的形态是按空格或分隔符取列。比如从access.log里提取访问 IP、请求时间和状态码：

awk '{print $1, $4, $9}' access.log | head -20

$1是第一列，通常是 IP，$4是时间字段，$9是状态码。日志里用空格或 tab 分隔的列，awk默认就用空格切分，非常方便。

更进阶一点的用法，比如统计每个 IP 访问次数：

awk '{count[$1]++} END {for (ip in count) print ip, count[ip]}' access.log | sort -k2 -nr | head -10

思路是把第一列 IP 当作数组下标累计，最后输出每个 IP 的访问次数并排序。这个命令审计、防刷、流量分析都在用，值得花时间搞懂原理。数组和循环的概念是理解awk的关键，但日常工作中你不需要写多复杂的awk脚本，掌握取列和简单统计就够了。

印象里有一次排查应用响应慢的问题，就是用awk按接口路径统计平均响应时间，锁定了两个慢接口，才发现是数据库连接池配置偏小导致的。日志分析从来不是炫技，是解决问题的手段。

4. 进程与系统状态：服务器卡了，第一件事做什么

4.1 top 的隐藏解读方法：别只盯着 CPU 百分比

top

服务器卡了，很多人的第一反应是执行top，然后看到%CPU那一列数值很高就慌了。但我要说的是，top输出的信息远不止那一列数据。

top最上面有系统负载平均值load average，后面跟三个数字。这个数值表示一段时间内处于可运行状态和不可中断状态的平均进程数。判断标准很简单：这个值如果长期大于 CPU 核心数，说明系统真的过载了。比如 4 核机器load average超过 4，就说明任务排队了。

top运行期间按P按 CPU 排序，按M按内存排序，按1展开所有 CPU 核心的使用率。这些快捷键比退出top重新敲命令高效得多。定位到占用最高的进程后，记下 PID，用top -p PID单独观察它，或者用ps看它的详细信息。

4.2 ps 查看进程：组合参数看懂进程全貌

ps aux

这应该是ps用得最多的组合。a显示所有终端的进程，u显示用户和资源占用，x显示无终端的进程。输出里PID是进程号，%CPU和%MEM是占用率，COMMAND是启动命令。

想查某个服务是否在运行：

ps aux | grep nginx

注意grep会把自己也匹配进去，输出里最后一行通常是grep nginx本身。看到这个不代表出了问题，是正常现象。更专业的做法是用pgrep -f nginx或ps aux | grep [n]ginx，用方括号里的字符类技巧排除 grep 自身。

查看进程的启动参数，很多时候排查问题要看服务是怎么起的：

ps -ef | grep java

这种输出能显示父进程 PID，对排查守护进程失效、服务被意外拉起等问题有帮助。比如你想知道某个进程是谁启动的，看PPID就能找到它的父进程，进而定位到启动脚本。

4.3 磁盘和内存：free、df、du 三兄弟

free -h df -h du -sh *

free -h看内存总量和剩余量，-h参数让输出更易读。很多人看到free输出可用内存很少就紧张，其实 Linux 会用空闲内存做缓存（buff/cache），这部分当内存紧张时会自动释放。判断内存是否不足，要看的是available列，不是free列。

df -h看所有挂载的文件系统使用情况。磁盘满了，数据库写不进去、日志打不出来，服务分分钟挂掉。df告诉你哪块盘满了，du -sh *快速找出当前目录下哪个子目录占空间最大，一步步定位到具体的大文件，这是清理磁盘空间的标准动作。

排查磁盘空间时还有个容易忽略的地方：进程删除了文件但没释放句柄，df显示空间还是满的。这种情况用lsof | grep deleted找到已经删除但仍被进程占用的文件，确认后重启相关进程就能释放空间。这个问题排查起来很绕，我遇到过两次，写出来给大家提个醒。

4.4 任务管理：前台后台切换和强制结束

ping 8.8.8.8 &

命令后面加&直接丢到后台运行。运行时Ctrl+C是中断前台进程，Ctrl+Z是把前台进程暂停并放入后台。暂停后用jobs查看后台任务列表，fg把后台任务调回前台，bg让暂停的后台任务继续运行。

进程杀不掉怎么办？先用kill PID发送 TERM 信号请求正常退出，隔几秒没反应再用kill -9 PID直接强制结束。-9是 SIGKILL，进程没有任何机会清理资源，非必要不用。但遇到僵死进程占用资源的时候，也别太犹豫，数据都保护不了的时候果断处理更重要。

5. 权限、网络与软件安装：新手最容易懵的三块

5.1 权限管理：chmod 和 chown 的数字逻辑

chmod 755 script.sh chown user:group file.txt

chmod后面的755是权限的数字表示法。每个文件有三组权限：属主、属组、其他人，每组三位。r读等于 4，w写等于 2，x执行等于 1，把数字加起来就是权限值。755表示属主有读、写、执行权限（4+2+1=7），属组和其他人有读和执行权限（4+1=5）。

chown修改文件属主和属组。部署 web 项目时，一个常见问题是文件属主不对导致 Nginx 或应用读不到，表现为权限拒绝。解决办法就是chown -R递归修改目录及子文件属主：

chown -R www:www /app/html

这个命令在日常部署中用到概率极高，秘诀就一条：-R必须带上，不然目录还是原来的权限，问题照旧。

5.2 端口和连接排查：netstat 和 ss

ss -tlnp

查看当前监听端口和对应进程。-t只看 TCP，-l只看监听状态的端口，-n不做域名解析，-p显示进程 PID 和名称。之前常用的netstat在新版系统上被ss替代了，但很多老教程还在写netstat，遇到提示命令不存在就换ss。

"端口被占用"是排查频率极高的问题。启动服务报Address already in use时：

ss -tlnp | grep 8080

找到占用 8080 端口的进程，然后决定是改服务端口还是处理那个进程。千万别不看占用进程就直接kill -9，我之前就手快杀掉了一个本该在跑的备份服务，导致当天备份任务失败。教训就是：先搞清楚占用者是谁，再决定怎么办。

5.3 远程操作与文件传输：scp 和 rsync

scp file.txt user@remote:/path/

基于 SSH 协议复制文件，好处是加密传输，缺点是不够高效。同步大量文件时用rsync：

rsync -avz ./local_dir/ user@remote:/path/remote_dir/

-a归档模式保留权限和时间戳，-v显示进度，-z压缩传输。rsync最强大的特性是增量同步，只传有差异的部分，再次执行时速度非常快。部署代码到测试环境，我都用rsync而不是打包上传解压，效率高很多。

注意源目录末尾带不带斜杠行为不同。rsync -avz src/ dest会把src里的内容复制到dest目录，而rsync -avz src dest会把src这个目录本身复制到dest里。这个区别我当年踩过坑，把整个目录套进去了，现在每次都专门确认路径。

5.4 软件安装：yum、apt 和日志查看入门

yum install -y nginx apt install -y nginx

CentOS 系列用yum，Debian/Ubuntu 系列用apt。两条命令的参数逻辑差不多，-y表示自动确认所有提示。新环境的第一个动作通常是换镜像源，因为默认源在国外，下载慢到怀疑人生，换完源安装速度立刻提上来。

查看系统日志最简单的方式：

journalctl -u nginx --no-pager -n 50

这是 systemd 时代的日志命令，查看某个服务最近的 50 条日志。传统方式看/var/log/messages也仍然有效，但journalctl更精准，直接按服务过滤。查 Nginx 启动失败的原因时，这条命令比打开一堆配置文件效率高得多。

6. 高频问题排查与避坑实录

6.1 命令找不到？先看 PATH 再怀疑安装

echo $PATH

新装的命令敲进去提示command not found，最常见的几个原因：一是命令确实没装；二是命令装在了/usr/local/bin下面但你的 PATH 没有包含这个目录；三是你用的是普通用户，命令装在 root 的目录下，需要sudo或切换用户。

排查手法分两步：

which nginx find / -name nginx -type f 2>/dev/null

which在 PATH 里查找命令的真实路径，找不到再用find全盘搜索看命令到底装在哪。定位到真实路径后，要么把这个目录加进 PATH，要么直接用绝对路径执行。用绝对路径验证是"命令可用"和"PATH 没配好"的最快区分方法。

6.2 管道和重定向：看懂 > 和 | 的区别

grep "ERROR" app.log > error.log grep "ERROR" app.log | wc -l

>是把命令输出写入文件，如果文件已存在会清空原内容重写。>>是追加写入，不覆盖原内容。|管道是把前一个命令的输出作为后一个命令的输入，用于串联多个命令。

区分理解：重定向是"输出到文件"，管道是"传递到下一个命令"。这个区别刚学时会混淆，类比一下：>是水龙头往桶里灌水，桶就是文件；|是水龙头接了根管子直接接到下一个水龙头上，水流不停。

管道再结合前面讲过的grep、awk、sort、uniq，就是一套完整的文本分析流水线，日常日志分析 90% 的需求都能覆盖。

6.3 误删恢复和操作习惯：最后说点保命经验

Linux 命令行没有回收站的概念，rm删掉就真的没了。除非你的文件系统专业级设备支持快照功能，否则普通环境里误删恢复基本只能靠教训。所以我的习惯是：

第一，删除前先ls确认当前目录和文件列表。

第二，重要文件删除前先压缩备份一份：

tar czf backup_$(date +%Y%m%d).tar.gz /important/directory

$(date +%Y%m%d)是取当前日期拼进备份文件名，这样每天备份都自动带时间戳。

第三，目录删除前先mv到一个回收目录，确认运行几天没问题后再真的删。

踩过几次坑之后，我现在在服务器上敲rm -rf的频率已经低到几乎为零。能用mv解决的，绝不用rm。能用find -delete配合-name精确匹配的，绝不用rm -rf大范围扫荡。

6.4 常见问题速查表：收藏这张表，能省半天排查时间

这些命令单个看起来都不难，难的是在高压场景下能快速想起哪条命令对应哪个症状。建议你把这张表保存下来，遇到问题先查表，用多了自然就记牢了。

我个人在实际操作中的体会是：Linux 命令的学习曲线不是一条直线，而是一个"接到任务→卡住→搜命令→尝试→解决→记住"的循环。很多人觉得条条命令都要背得滚瓜烂熟才算学会，其实真正重要的是掌握一套排查思路：先确认问题现象，再用命令收集信息，最后定位原因动手解决。命令只是这套思路的载体。最后再分享一个小技巧：每次解决一个让你卡了超过十分钟的问题，就把"问题现象 + 解决命令"记到你的笔记里，一个月后你就会拥有一份属于自己的、比任何教程都珍贵的速查手册。