企业官网建设流程全解析

我先讲个很多新手都会问的问题：Linux 命令这么多，几百上千条，到底怎么记才不头大？我的答案不是“背”，而是“分类”。把命令按照使用场景拆成几块，每块记住它的核心逻辑，剩下的边用边查，这才是正经路子。我自己带过不少新人，也算过烂不少坑，最后沉淀下来的就是一份按场景划分的 Linux 常用命令速查表。这篇就把它完整写出来，配合每个块的实战心得，你照着用就行。

先说这份内容到底能解决什么问题：不管你是刚接触 Linux 的准运维、写代码但经常要在服务器上排查问题的开发、还是准备面试的大学生，这份分类速查表都能帮你快速定位命令。它不追求把所有命令列全，而是把最高频、最容易踩坑、最能在关键时刻救命的那部分拿出来，按“文件、文本、权限、进程、网络、存储、开发工具、系统管理”这条主线铺开。你可以把它当工具书用，也可以当复习提纲用。

1. 先想清楚：命令为什么不按字母背，而是按场景分类

1.1 理解 Linux“一切皆文件”的设计哲学

Linux 和 Windows 最大的差别，不是有没有图形界面，而是底层逻辑。Windows 把磁盘分成 C 盘、D 盘，操作系统、软件、数据各占一摊；Linux 则是把所有资源——硬盘、键盘、网络、进程、配置，全部抽象成文件。你操作文件用的是一套命令，操作硬件用的还是那套命令，只是路径不同而已。

理解这点之后，很多命令就不用死记了。比如你改网络配置，实际上是在编辑/etc/sysconfig/network-scripts/ifcfg-eth0类似的文本文件；你看 CPU 信息，cat /proc/cpuinfo；你看内核日志，dmesg本质也是读文件。所以我在整理速查表时，第一栏永远是文件操作，因为它是整个系统的基础。

1.2 我给速查表定的五条主线

我整理表格的时候，不是按字母 a-z 排，而是按一个运维或开发人员的操作顺序排：先看有什么（文件目录），再改内容（文本编辑），再调属性（权限用户），再看跑没跑（进程服务），最后收尾找问题（日志网络）。这个顺序对应着你解决一次线上问题的完整过程。

举个例子，你接到一个告警说服务挂了。第一反应是什么？先ls看下目录结构、确认部署路径对不对；再tail看日志、确认报错原因；ps看进程是不是还活着；ss看端口有没有监听；df看磁盘是不是满了。这五条主线一套下来，80% 的问题都能定位。所以不要东一榔头西一棒子地学命令，按场景学、按问题路径学，效率最高。

2. 高频命令分类拆解：从文件操作到文本处理

2.1 文件与目录操作：这是所有命令的地基

这一组命令我默认每个人都要形成肌肉记忆：ls、cd、pwd、cp、mv、rm、mkdir、touch、find。很多新手会轻视这组，但恰恰是它们最容易翻车。

几个值得注意的细节：

• ls -l看到的文件权限、属主、大小、时间，是判断文件状态的第一手信息。ls -lhtr按时间倒序，日志轮转时非常好用。
• rm -rf一定要警惕。我在生产环境见到过太多人因为写错了路径，把整个应用目录删光。我的习惯是删除前先mv到一个/tmp/垃圾箱目录，观察一天没问题再删。这个习惯帮我挡过好几次大事故。
• find命令不是只用来搜文件名的。find . -name "*.log" -mtime +7 -delete可以清理 7 天前的日志；find / -perm -4000可以找出所有 setuid 文件，排查安全风险也靠它。配合-exec还能批量处理。

2.2 文本处理四件套：grep、sed、awk、cut

这是整个速查表的精华区。不懂这四件套，你只能算“会用 Linux”，懂了才算“会玩 Linux”。

grep的目标是从一堆文本里过滤出关键行。最常用的不只是grep 关键字 文件，而是grep -r 关键字 目录递归搜索整个目录，以及grep -v排除、grep -E用正则。排查日志时，grep "ERROR" app.log | head -50能快速看到最近的报错。

sed是做替换和编辑的。最经典的用法是sed -i 's/old/new/g' file，把文件里的所有 old 替换成 new。注意-i是直接改原文件，加上它会覆盖，不加就只是输出到屏幕，不会修改文件。新手经常忘了-i，替换完发现文件没变，还以为命令错了。

awk是列处理神器。默认按空格分列，awk '{print $1, $3}'取第一和第三列。进阶用法awk -F':' '{print $1}' /etc/passwd按冒号分隔，把系统所有用户名列出来。配合条件过滤awk '$3 > 100 {print $1}'能完成简单统计。

cut更轻量，适合按分隔符切列。比如cut -d: -f1 /etc/passwd和上面 awk 效果一样，但语法更简洁。我自己的习惯是：简单切列用 cut，要做条件判断和统计用 awk。

2.3 权限与用户：chmod、chown、useradd 的正确姿势

权限命令是 Linux 安全的闸门。chmod 755 file、chmod +x script.sh大家都会，但有几个容易忽略的点。

chown除了改属主，还能改属组：chown root:root file。更实用的是用-R递归改目录，比如部署应用后需要把整个目录改成 nginx 用户：chown -R nginx:nginx /data/www。这里有个实际问题：改了属主却发现服务还是没权限读，很可能是目录中间层的权限没放开，比如/data本身的权限是 700，下面子目录设置得再好也不行。

用户管理方面，useradd建用户后要立刻passwd 用户名设置密码。生产环境更推荐useradd -s /bin/bash -m 用户名明确指定 shell 和建家目录。顺带提醒一句：不要把 sudo 权限配得太宽松。visudo里给用户配ALL=(ALL) NOPASSWD: ALL那条，等于把服务器钥匙挂门口，我见过很多服务器就是这么被掏空的。给最小化权限、用sudo审计日志，这才稳。

我写命令时有一条“三板斧”原则：先把权限、属主、路径打印清楚，再动手操作。比如执行chmod前先ls -l看当前状态，执行删除前先find看目标内容。磨刀不误砍柴工，至少能防止一半以上的人为失误。

3. 运维场景实战：日志、网络、磁盘一套带走

3.1 日志排查：tail、grep、less 的黄金组合

线上故障排查，日志是唯一可信的现场。我的组合拳是：tail -f看实时输出，grep过滤关键字，less翻长文件。

• tail -f /var/log/app.log实时跟日志，服务启动时这行命令能让你看到报错是不是打印在最后几行。
• tail -n 500 app.log | grep ERROR看最近 500 行里所有报错，比直接打开几百 MB 的日志文件省太多事。
• 遇到超大日志文件，别用 vim 打开，直接用less。它不会一次性把整个文件读进内存，几十 GB 的文件也能翻得动。在 less 里按/关键字搜索，按n连续匹配，这是查长日志的利器。

还有一个做法值得推荐：把多台机器的日志聚合到一个 MySQL 或 Elasticsearch 里，用 SQL 或 Kibana 查，效率远胜手割 ssh。但如果手头没有集中式平台，掌握好 tail、grep、less 的组合，单机排查完全够用。

3.2 网络诊断：curl、ping、ss、traceroute 从外到内

网络问题是最容易让人抓狂的。我习惯按“从外到内”的顺序排查：先确认能不能出去（ping 外网），再确认服务有没有监听（ss），再确认端口通不通（nc、telnet），最后用 curl 实际请求一次看返回码。

• ping 目标IP测连通性，但很多云厂商会禁 ICMP，ping 不通不一定是网络断。
• ss -lntp列出所有正在监听的端口及对应进程，比老命令netstat输出更清晰。ss -ant看所有 TCP 连接状态，排查大量 TIME_WAIT 时就靠它。
• curl -I http://域名看 HTTP 响应头，返回 200、301、502 分别代表什么状态，这是判断 web 应用好不好用的第一手证据。
• traceroute IP追踪路由路径，能看出是哪一跳出了问题。实际上很多网络问题出现在中间运营商或防火墙，traceroute 可以帮你快速定位到具体节点。

一条实战经验：当应用提示连接超时，先别急着重启服务。先在服务器本机curl一次，通了说明服务没问题，是外部链路；再用另外一台同网段服务器测，通了说明是客户端到你服务器这一段的问题。一层一层剥，比两眼一抹黑强太多。

3.3 磁盘存储：df、du 和挂载 NAS 的实战

磁盘满了是运维遇到最多的故障之一。df -h看整体使用率，du -sh *看当前目录下每个子目录占多大。

分享一个处理磁盘满的完整流程：执行df -h看到/分区 100%，先du -sh /usr/*、du -sh /var/*逐层排查，找到大目录后进去再du -sh * | sort -rh | head -20，按大小排序直接找到最大的几个文件。清理时优先处理日志和临时文件，千万别随便删其他文件，避免误删。

挂载 NAS 存储也是高频需求。NFS 挂载这里有个完整的步骤：

1. 先查看服务端共享目录：showmount -e NAS服务器IP。
2. 创建本地挂载点：mkdir -p /data/nas。
3. 手动挂载：mount -t nfs NAS服务器IP:/共享路径 /data/nas。
4. 验证：df -h | grep nas，确认挂载成功。
5. 写入/etc/fstab实现开机自动挂载，格式大概是：

   NAS服务器IP:/共享路径 /data/nas nfs defaults,noatime 0 0

6. 执行mount -a试验 fstab 配置有没有写错。

这里最容易出问题的就是权限和防火墙。挂载后看到的内容是只读、或者根本报错“Permission denied”，八成是 NFS 服务端导出的权限没配好，或者本机防火墙没放行。建议先在客户端执行rpcinfo -p NAS服务器IP确认 nfs 服务正常，再排查防火墙。

3.4 进程与性能：ps、top、free、vmstat 这一套

进程管理是检查系统健康的关键。ps -ef看完整进程列表，ps -aux按资源占用排序输出，两者都能定位进程 ID。需要杀进程时，kill -9 PID是强制杀，kill -15 PID是优雅终止。

top动态看 CPU 和内存占用，进去按P按 CPU 排序、按M按内存排序，按q退出。这是找“是谁把资源吃光了”的第一现场。

free -h看内存。注意 Linux 的缓存机制，很大一部分 Buff/Cache 是可以回收的，不要看到用了 90% 就以为是泄漏。判断内存压力别光看 free，要看 swap 是否增长，以及vmstat 1里 si/so 两列是否频繁交换。

我给性能排查列过一张参数速查表：

这套命令配合下来，基本能回答“服务器为什么慢”这个大问题。

4. 开发与学习场景：从脚本到容器全家桶

4.1 脚本基础：变量、循环、定时任务

写脚本是 Linux 能力的分水岭。不会脚本，你每次都得手动敲命令；会脚本，重复工作就是一行./xxx.sh的事。

脚本第一行是#!/bin/bash，声明解释器。变量赋值用name="value"，读取要加$name或${name}。条件判断用if [ -f "$file" ]; then ...; fi，注意方括号里面有空格，很多人第一次写就栽在这。循环最常用的是for i in $(seq 1 10); do ...; done。

定时任务统一交给 crontab。crontab -e编辑、crontab -l查看、crontab -r删除。格式是“分 时 日 月 周 命令”。0 3 * * * /data/backup.sh表示每天凌晨 3 点执行一次备份脚本。注意脚本路径要写绝对路径，脚本内涉及的环境变量有时不会自动加载，最好在脚本开头显式定义，否则定时任务跑出来的结果跟手动跑完全不一样。

我踩过一个大坑：写了个清理脚本，手动执行很正常，但 crontab 里不生效。后来发现是脚本在第一行没有完整声明 bash 路径，因为 crontab 默认使用精简环境。处理方法是所有生产用脚本第一行都写#!/bin/bash，并且不要依赖用户环境变量。

4.2 版本协作：git 高频命令

开发环境绕不开 git。很多开发在 IDE 里点鼠标点习惯了，一到服务器上就抓瞎。其实掌握几条就够日常用：

• git clone 仓库地址拉取代码
• git status看当前改动
• git add .暂存所有改动，git commit -m "说明"提交
• git pull拉取更新，git push推送
• git log --oneline看提交历史
• git branch -a列出所有分支，git checkout -b 新分支名创建并切换
• 合并分支git merge 分支名
• 想撤销文件修改：git checkout -- file或git restore file

这里提醒一句：在服务器上直接改线上代码前，一定先git status看清当前分支和改动，再决定用不用git pull --rebase。直接git pull遇到本地有未提交改动时经常会报冲突，处理起来很烦。我的习惯是在服务器上只做拉取和部署，不直接在服务器上写新功能。

4.3 容器与中间件：docker、redis-cli 高频命令

容器环境已经是标配，docker 命令必须手熟：

• docker ps看运行中的容器，加-a连停止的一起看
• docker logs -f 容器名跟日志
• docker exec -it 容器名 bash进入容器内部
• docker restart 容器名重启
• docker stop / start停止和启动
• docker build -t 镜像名:标签 .构建镜像
• docker images看镜像列表，docker rmi 镜像ID删镜像
• docker-compose up -d一键启动一组服务

进入容器排查问题时，有个细节：很多容器是最小化安装，里面没有 vim、没有 curl。所以要么在容器内用apt-get install临时补装，要么用docker inspect 容器名在宿主机侧看配置，用docker cp 宿主机文件 容器名:/容器路径传文件。

redis-cli 也是一个常用点。redis-cli -h 127.0.0.1 -p 6379连库，redis-cli ping返回 PONG 说明服务正常。生产环境执行redis-cli keys "*"要非常谨慎，大库下这条命令会阻塞整个 redis。真要检查数据量，用redis-cli dbsize。查某一个 key 的值，用redis-cli get key名。

4.4 调试工具：gdb 和 adb 的那些高频操作

gdb 是 Linux 下 C/C++ 程序调试的标配。最常用的几个命令：

• gdb ./程序名启动调试
• break 函数名或break 行号设置断点
• run开始运行
• next单步执行，不进入函数
• step单步执行，进入函数
• print 变量名查看变量值
• bt查看函数调用栈
• continue继续运行到下一个断点
• quit退出 gdb

排查段错误时，bt能直接打印崩溃时的调用栈，定位是哪一行的野指针问题。如果是定位已经崩溃的程序，可以打开 core dump 再用 gdb 分析：gdb ./程序名 core文件。

至于 adb，做安卓开发或者嵌入式开发时用得较多。adb devices查看设备，adb shell进入设备 shell，adb install app.apk装应用，adb logcat抓日志。真机调试时如果找不到设备，先adb kill-server再adb start-server，多半是 adb 服务卡住了。

嵌入式 Linux 场景下还会遇到 DSA switch 驱动的调试，这类通常要看ip link、bridge link和内核日志。我没有太强的嵌入式背景，但从经验上讲，调试思路跟服务器排查是一致的：先确认设备状态，再抓日志，再查驱动上报的信息。

5. 面试与系统概念：Windows 对照与高频考点

5.1 一张对照表搞定概念迁移

很多人是从 Windows 转过来学 Linux 的，最大的障碍是记忆习惯。我列一张对照表，能帮你把旧知识迁移过来：

对照表的意义不只是背单词，而是帮你理解两种系统解决问题的大致方向。你会用dir就会用ls，你会用ipconfig就会用ip addr。学习期间先拿熟悉的 Windows 行为做锚点，慢慢过渡到 Linux 原生的思维方式。

5.2 面试里常被问的：IPC、链接与启动流程

面试 Linux 岗位，高频考点除了命令，还会问机制。这些地方我也一并整理出来。

• 进程间通信（IPC）：管道、信号、共享内存、消息队列、套接字。一条命令能配合理解，比如ps aux | grep nginx里的|就是管道。深入一点会问到shared memory和mmap的区别。实际运维中排查两个服务之间通信异常，经常要检查是不是共享内存段没清理干净。
• 硬链接与符号链接：ln file link建硬链接，ln -s target link建软链接。硬链接和原文件共享同一个 inode，删掉一个不影响另一个；软链接有点类似 Windows 的快捷方式，目标删掉它就成了死链。面试常问区别，运维中改配置也常用软链接切换版本。
• 系统启动流程：从 BIOS/UEFI 到引导加载程序再到 init 系统。CentOS 7 之后用 systemd 管理服务，所以systemctl start nginx、systemctl enable nginx必须要知道。查看之前系统启动日志，用journalctl -xb。

这些概念光背不行，要配合实际操作去理解。比如自己建一个软链接、读一次cat /proc/进程ID/status看进程状态，比死记硬背有效得多。

6. 常见问题与排查技巧实录

6.1 命令找不到、权限不够，先看这四个方向

“command not found”是出现频率最高的错误提示。遇到这个情况先别慌，按顺序排查：

• 命令是不是安装过？比如htop没装就是 not found，包管理器装一下即可。
• 命令是否存在但不在 PATH 里？/usr/sbin/下的命令普通用户可能用不了，加上完整路径执行。
• 是不是环境变量没生效？改完/etc/profile后执行source /etc/profile。
• 权限被限制？ls -l看看执行权限位，没有 x 权限就无法执行。

6.2 NFS 挂载失败，可能不是命令的问题

挂载 NAS 命令本身很简单，但失败的原因五花八门。我按概率排一下常见原因：

1. 服务端没启动 NFS 服务，showmount直接就报错。
2. 客户端没装 nfs-utils，导致mount -t nfs不支持。
3. 防火墙没放行 2049、111 端口。
4. 挂载参数写错，比如漏了nfsvers=4。
5. /etc/fstab 写错导致开机卡住，这时可以进入紧急模式修复，或先用mount -a验证再重启。

我看过太多人在第四、第五个问题上折腾一整天。我的建议是：先把手动挂载调通，再写 fstab。手动都挂不上，写成自动挂载只会更难排查。

6.3 日志文件越来越大，定期轮转怎么做

日志爆盘是最常见的磁盘故障源。除了手动清理，更推荐用系统自带的 logrotate。它的配置文件在/etc/logrotate.d/下，为你的应用写一个配置：

/data/app/app.log { daily rotate 7 compress missingok notifempty copytruncate }

这段配置的含义是：每天轮转一次，保留 7 份，旧的压缩，应用还在写日志时用 copytruncate 方式复制再清空，避免服务句柄失效。配置好以后先用logrotate -d /etc/logrotate.conf干跑调试一下，没问题再正式启用。

6.4 六条避坑建议，都是真金白银换来的

最后分享几条我这些年攒下的经验，不是什么文档里都会写的：

1. 删除前先 mv 到临时目录，观察一天再删。这招救过我很多次。
2. 批量命令前先 echo 或 dry-run 验证。比如要批量重命名文件，先跑一遍只打印不改动，确认没问题再真正执行。
3. 修改系统配置文件前先备份。cp file file.bak，一行命令，关键时候能让你免于重装系统。
4. 不要在高峰期执行大范围 find、grep 扫描全盘。CPU 和 IO 被拉满，用户就卡住了。
5. 用nohup 命令 &运行后台任务时，注意确认输出重定向。不重定向的话，默认输出到 nohup.out，时间长了照样把磁盘撑满。
6. 连接服务器务必使用密钥认证，少用密码登录。CentOS 和 Ubuntu 最近的版本都开始默认禁止密码登录，这个趋势要跟上。

这些经验看着零碎，但每一条背后都有真实事故的教训。工具用法过一两个月会生疏，这类思维习惯会一直留着，帮你省掉无数加班时间。

我自己留这份速查表的方式很简单：放在~/cheatsheet/目录下，用 Markdown 写好，遇到问题先翻一遍，再结合man命令看详细说明。时间长了，哪些命令常用、哪些参数最顺手，你会形成自己的肌肉记忆。最后想提醒一句：命令只是工具，真正值钱的是你排查问题时的思路。先把这几十条命令用熟，再渐渐扩充，你的 Linux 功底就会像滚雪球一样越来越厚。