企业官网建设流程全解析

接手一台云服务器，第一件事永远是面对一个黑乎乎的终端窗口。很多朋友在云厂商控制台买了实例，重置密码、开放端口、远程连接一气呵成，结果看到命令行界面就懵了——网上搜"Linux常用命令"能出来上千条结果，但没人告诉你哪些命令是你真正每天都会用到的，哪些只是为了应对面试题。

这篇文章不打算罗列一百个命令，那没有任何意义。我按一个实际场景来讲：假设你刚买完一台云服务器，从SSH登录开始，到部署一个服务，到某天网站打不开排查问题，这一路你会先后碰到哪些命令、每个命令是干什么的、盯着输出看什么。这十几条命令覆盖了云服务器日常运维的九成场景，看懂它们，你就有了独立折腾一台Linux服务器的底气。

不管你的服务器是Ubuntu、Debian、CentOS还是Rocky Linux，不同发行版的软件包管理命令略有差异，但文件操作、权限、进程、网络这些底层命令几乎完全一致。下面这些内容，是我自己从最早买第一台云服务器到现在，反复踩坑之后浓缩出来的东西。

1. 登录后的第一轮检查：把服务器"家底"摸清楚

1.1 SSH登录不是只有密码这一条路

先说说你怎么进到服务器里面。最常用的方式是通过SSH协议，Windows用户用终端或者Xshell、Windows Terminal，macOS用户直接在终端里敲命令：

ssh root@你的服务器IP

也可以指定登录用户，比如你创建了一个叫deploy的用户：

ssh deploy@你的服务器IP

回车之后会让你输密码。这一步很多人会忽略一个小细节：云服务商的密码规则通常比较严格，但如果你设了一个复杂密码，建议立刻换成SSH密钥登录。密钥登录本质上就是一对公钥和私钥，公钥放在服务器上，私钥留在本地，配对成功才能进。操作也很简单，先在本地生成密钥：

ssh-keygen -t rsa -b 4096

生成的公钥默认在~/.ssh/id_rsa.pub，然后把公钥内容追加到服务器的~/.ssh/authorized_keys文件里，或者用一行命令直接远程写入：

ssh-copy-id root@你的服务器IP

配好之后再用ssh登录，系统会直接放行，不再问密码。为什么这件事值得花五分钟做？因为我见过太多人用密码登录，弱密码被扫描爆破，服务器被植入挖矿程序。云服务器默认暴露在公网上，每天被自动化脚本扫描是常态，密钥登录能从根上解决密码爆破问题。

1.2 几条命令看清CPU、内存和磁盘

登录成功之后，先别急着装东西，花一分钟确认你买的机器实际配置和你想象的一致。相关命令不多，就三个：

lscpu # 查看CPU型号、核心数、架构 free -h # 查看内存总量和用量，-h 是human可读格式 df -h # 查看磁盘分区和用量

lscpu会输出一大段信息，但你只需要关注两个地方：一是Model name（CPU型号），二是CPU(s)（逻辑核心数）。如果你买的实例是2核，这里显示2就对了。

free -h的输出里有一行Mem:，看total列和available列。很多人第一次看到used占用特别高就紧张，其实Linux的内存管理和Windows不太一样，它会尽量把空闲内存用作文件缓存（就是输出里的buff/cache），这部分内存是随时可以释放给应用用的，所以不用盯着used看，available才是真正可以用的内存总量。

df -h看的是磁盘，重点看根分区/的Use%。如果云服务器系统盘只有40G，而你装了一堆东西，Use%涨到80%以上，就该考虑清理日志或者扩容了。磁盘满这个坑我在运维里见过太多次，网站突然打不开、数据库写不进去，一查往往是df -h显示100%。

1.3 系统时间也不容忽视

没接触过服务器的人通常不会意识到时间同步有多重要。日志排错、定时任务、HTTPS证书校验全都依赖系统时间。你可以在登录后顺手敲一下：

date timedatectl

timedatectl输出里如果System clock synchronized: yes，说明时间同步正常。云服务器一般会预装时间同步服务，通过NTP协议从内网时间源定期校时。如果哪天你发现服务器日志里的时间错了好几个小时，先查这个。时间不对的情况下，你用curl访问HTTPS接口都会报证书错误，这种问题排查起来很容易绕弯路。

搞清楚了这几项基础信息，你对这台服务器就有了一个大致判断：几核、多大内存、磁盘空间多少、系统时间准不准。下一步就可以正式进入日常操作了。

2. 文件和目录操作：从 cd 到 tar，这些命令占据了七成日常

2.1 先认清Linux的目录结构

Windows用户刚切换到Linux时，最大的不适应是路径。没有C盘D盘的概念，一切都从/开始。你不用记全部目录，但下面这几个必须知道：

• /root是root用户的家目录，你现在默认就在这
• /home是普通用户家目录的集合
• /etc存放系统配置文件，比如网络配置、软件源配置
• /var/log存放各种服务的日志文件，排错全靠这里
• /tmp临时目录，重启后会清空

你自己部署的应用代码，通常放在/root、/home/用户名或者/opt下面。记住一个原则：别去乱动系统目录里的文件。我们有时会图方便，用chmod 777或者改/etc底下的配置，改坏了系统起不来，那时候就不是删掉重来能解决的了。

2.2 高频命令组合拳

平时最常用的几个基础命令，我直接列一下用法：

pwd # 查看当前路径 ls # 查看当前目录内容 ls -lh # 带文件大小、权限等详细信息 cd /var/log # 切换目录 mkdir -p app/logs # 递归创建目录，-p 表示父目录不存在时自动创建 cp -r html html_bak # 递归复制目录 mv html html_old # 改名或移动 rm -r html_old # 删除目录，-r 表示递归

有几个细节值得单独说。ls -lh里的-l是长格式，会显示权限、属主、大小、修改时间；-h是让文件大小以K、M、G这样的单位显示，不写-h的话是一堆字节数，看着费劲。mkdir -p在创建多级目录时特别好用，比如你要创建/data/project/logs，没有-p会报错，加了-p一步到位。

cp -r拷贝目录的时候必须带-r，否则会报错说cp: omitting directory，这是新手最容易碰到的一个报错。mv不需要加参数，既可以重命名也可以移动，所以一般用来改名和挪位置。

这里必须郑重提醒一句rm的危险性。云服务器上因为误删数据哭的人非常多，而且很多是rm -rf一把梭。服务器上删除是不可恢复的，云盘快照如果没做，数据彻底没了。我的习惯是：删除前先mv到一个临时目录，确认没问题再过几天清掉。尤其是对数据库数据目录、代码仓库这类东西，绝对不要手滑用rm -rf。

2.3 文件传输与解压：部署服务器的必经环节

搞云服务器必然涉及把本地文件传到服务器上。最简单的两种方式：

# 从本地复制到服务器 scp /本地路径/文件.zip root@你的服务器IP:/root/ # 从服务器下载到本地 scp root@你的服务器IP:/root/文件.zip /本地路径/

如果你的项目文件比较大，或者目录很多，可以用rsync，它能增量同步，断点续传，传大目录比scp靠谱得多：

rsync -av /本地目录/ root@你的服务器IP:/root/目标目录/

服务器上传过来的压缩包需要解压，一个命令打天下：

tar -xzvf 文件名.tar.gz # 解压 .tar.gz 格式 unzip 文件名.zip # 解压 .zip 格式

反过来，打包上传本地目录可以用：

tar -czvf 文件名.tar.gz /要打包的目录

tar参数很好记：-c是创建（create）、-x是解压（extract）、-z是gzip压缩、-v是显示过程、-f是指定文件名。组合一下就行。

我还遇到过一个情况，帮人排查部署问题，发现他全程用手工方式在服务器上编辑配置文件，几百行的Nginx配置硬是一行行敲进去，改一处错一处。其实更好的做法是本地改好，用scp传上去，改错了也有备份。很少有人叮嘱这一点，但对于部署任何服务都是更稳的做法。

3. 权限管理：Permission denied 是最常见也最好解决的一类问题

3.1 rwx 权限模型一次看懂

你在Linux里执行ls -l，会看到每行开头像drwxr-xr-x这么一串，这就是文件的权限位。我刚开始也嫌它难记，后来发现可以用一个很简单的思路理解：这串字符分成4段，第一段是d表示这是个目录；后面三段分别表示属主权限、组权限、其他人权限，每段里的r是读、w是写、x是执行，-就是没有这个权限。

比如说-rw-r--r--，表示这是一个普通文件，属主能读能写，其他人只能读。再配合数字用法：r=4、w=2、x=1，所以rwx就是7，r-x就是5，r--就是4。于是常见的chmod 755意思就是属主完全控制，其他人的权限是读和执行：

chmod 755 脚本.sh # 给所有用户读和执行权限，属主可写 chmod 644 配置文件.conf # 属主可读写，其他人只读 chmod -R 755 /var/www/html # -R 递归修改整个目录

修改属主和属组用chown：

chown root:root 文件名 # 修改属主和属组 chown -R www:www /var/www # 递归修改，部署网站时很常用

3.2 遇到 Permission denied，先看属主再看权限

很多刚接触服务器的人一看到Permission denied就照着网上的教程chmod 777，把文件权限改成所有人可读可写可执行。这种做法虽然能暂时解决报错，但等于把门彻底敞开，安全风险极高。

正确排查顺序是这样的：

1. 先看这个文件或目录属于哪个用户和组：ls -l
2. 再看你当前登录的是哪个用户：whoami
3. 确认你要执行的动作和权限位是否匹配

举个例子，网站根目录如果是root拥有的，而PHP-FPM或Nginx进程跑在www用户下，那www用户写不进去，就会报Permission denied。这时候正确做法是把目录属主改成www：

chown -R www:www /var/www/html

而不是粗暴地chmod 777。对目录来说，还有一个非常容易忽略的细节：想进入一个目录、读取里面的文件，不仅文件本身要有读权限，从根路径下来的每一层目录都要有执行权限。也就是说/var/www/html里的文件要能读，/var、/var/www、/var/www/html都要有x权限。我们曾经排查一个问题，所有文件权限都正常，但网页一直403，最后发现是中间某层目录被改成了drwxr--r--，缺了执行权限，谁能想到问题在那里。

3.3 别一直用 root 操作，建个普通用户

默认登录云服务器用的都是root，这对个人玩具服务器来说没有大问题，但养成好习惯的话建议建一个普通用户，日常操作走sudo。好处是：即使你敲错了一个命令，影响的只是这个用户自己的文件，而不是整个系统。创建用户这几条命令是必会的：

adduser deploy # 交互式创建用户 usermod -aG sudo deploy # 给用户sudo权限，Debian/Ubuntu用sudo组 passwd deploy # 设置密码 su - deploy # 切换到该用户

之后用它登录，需要管理员操作的时候：

sudo systemctl restart nginx

sudo执行时需要确认你是这个用户本人，不是随便什么人就能用的。养成这个习惯之后，你会少摔很多跟头。

4. 系统状态与进程：用数字判断"卡不卡"，而不是凭感觉

4.1 top 和 free 的读法

服务器出问题时，你第一反应应该是看系统资源到底够不够。我见过很多人凭感觉判断"服务器卡了"，然后盲目重启，重启完问题照旧。实际上形成一套固定的体检动作更高效：

top

top命令界面里，最上面一行有一个load average，后面跟着三个数值，比如0.08, 0.03, 0.01。很多新手第一次看会犯迷糊，不知道三个值的意义。其实很简单：它们分别表示过去1分钟、5分钟、15分钟的系统平均负载。一个粗略的判断基准是，这个值如果接近你CPU核心数（比如2核机器load到2左右），说明系统已经开始繁忙了，超过核心数持续一段时间，说明已经过载。三个数值里，重点看5分钟和15分钟，因为1分钟内的瞬时值容易受到偶发波动的影响。

界面下方的进程列表里，按Shift + P按CPU排序，按Shift + M按内存排序，可以直接看出是哪个进程在吃资源。如果看到某个陌生进程CPU占满100%，大概率是被入侵植入了挖矿脚本，这就是另一个话题了。

退出top按q。内存使用直接看free -h也行，刚才登录检查时已经提过。另外还有一个更友好的工具叫htop，在Ubuntu上可以用apt install htop装上，界面有颜色、可以直接看每个核的占用、鼠标操作，用起来比top顺手很多，服务器不太卡的场景下可以优先用它。

4.2 找到并处理异常进程

如果你的某个服务进程要手动启动、查看或停止，最常用的命令是：

ps aux | grep nginx # 查找nginx相关进程 kill 1234 # 结束进程ID为1234的进程 kill -9 1234 # 强制结束，慎用

ps aux会把系统所有进程列出来，加上| grep nginx，就是只显示和nginx有关的行。管道符在这里的作用是把前一个命令的输出作为后面命令的输入，这是Linux命令组合的最基础方式，之后你会在无数地方见到它。

kill是给进程发信号，默认发的是TERM信号，请求进程自行退出，它自己会去清理资源、正常退出。如果进程卡住不响应，再加-9强制杀掉。但-9这种暴力方式要慎用，尤其对数据库这类有状态的服务，强制杀可能造成数据不一致。

在现代服务器上，服务一般由systemd管理，你可能更常用的是下面这套：

systemctl status nginx # 查看服务状态 systemctl start nginx # 启动服务 systemctl stop nginx # 停止服务 systemctl restart nginx # 重启服务 systemctl enable nginx # 设置开机自启

systemctl的输出里会告诉你这个服务当前是active (running)还是failed，还能看到最近几条日志，如果服务起不来，它往往是排查的第一站。

4.3 关于 Load Average 的常见误判

关于负载，还有一个常见的误区值得提醒一下。有很多人误以为load average高就是CPU占用率高造成的。其实负载的含义不仅是CPU，还包括等待磁盘I/O和锁的进程。也就是说，如果磁盘卡了，一堆进程在等待I/O，load也可能高得吓人，而CPU占用率并不高。

有一次我收到告警说服务器load到了7，赶紧登上去看，top里CPU占用才不到20%，再一看iostat和vmstat，是磁盘I/O被打满了。后来排查发现是日志轮转脚本在同时压缩大量日志文件，磁盘IO被压缩进程占满。这种场景如果光看CPU，你永远找不到问题所在。所以看到高负载，别忘了结合磁盘和内存情况一起看，这比单看一个指标可靠得多。

5. 日志与网络排错：遇到问题时的完整排查链路

5.1 日志文件怎么读才有效

服务器上某个服务出问题了，最有效的排查入口永远是日志，而不是瞎猜。系统日志在/var/log目录下面，不同的服务有自己的日志。比如：

• /var/log/nginx/access.log和error.log是Nginx的访问和错误日志
• /var/log/syslog是系统整体日志
• 用systemd管理的服务可以用journalctl -u 服务名查看专属日志

看日志一般两种方式，一种是直接看全部，但日志往往很长，通常都是看最后一段：

tail -n 100 /var/log/nginx/error.log # 查看最后100行 tail -f /var/log/nginx/error.log # 实时滚动输出，观察新日志

tail -f很重要，在复现问题的时候开着它，然后去触发一次错误，屏幕上就会立刻蹦出来新的错误信息，定位问题特别快。排查完之后按Ctrl + C退出。

从一大段日志里捞关键信息，用grep：

grep "ERROR" /var/log/nginx/error.log grep "500" /var/log/nginx/access.log | tail -20

grep是Linux里的必备工具，它可以在文件内容里搜索关键词。后面如果觉得操作复杂，再学一下|管道和这几个基础工具，就能完成很多灵活的查询。

5.2 网络排查：从IP配置到端口连通性

网站打不开了，或者服务器连不上外网了，这是一条非常经典的排查链路，我建议你牢牢记住顺序。

第一步，先看网卡有没有IP，网络是不是通了：

ip addr ping -c 4 8.8.8.8

ip addr会显示各网卡的状态和IP地址。如果你需要配置IP，也是在这个命令的输出基础上做调整。ping发几个ICMP包过去，能通说明网络链路正常。如果IP都有但ping不通外网，可能是网关或路由的问题，大概率要联系云服务商或者查安全组了。

第二步，如果你域名打不开，先确认域名能不能解析到正确的IP：

getent hosts yourdomain.com nslookup yourdomain.com

解析结果应该指向你服务器的公网IP，如果不对，去云服务商的DNS控制台改解析记录。

第三步，确认服务器本地的Web服务是否在正常运行：

curl -I http://localhost

curl -I只获取响应头，如果返回HTTP/1.1 200 OK，说明本地服务正常。

第四步，从你的电脑或者别的机器上测试远程端口是否通：

telnet 你的服务器IP 80

如果telnet连不上，说明请求没到你的服务，问题出在防火墙或安全组。说到这个就要提到云服务器特有的"双重门"了。

5.3 云服务器特有的双重门：安全组和系统防火墙

云服务器的网络策略是两层，第一层是云控制台里的安全组，第二层是操作系统里的防火墙，比如firewalld、ufw或者iptables。我遇到太多人把80端口开了系统防火墙却忘了安全组，或者反过来，安全组全放开了却忘了系统防火墙，最后怎么都访问不了。

登录云服务商控制台，找到安全组或防火墙规则，确认你要用的端口（比如80、443）已经放行，来源IP写0.0.0.0/0表示允许所有IP访问。系统里面，CentOS/Rocky用这个：

firewall-cmd --list-all # 查看防火墙规则 firewall-cmd --add-port=80/tcp --permanent # 放行80端口 firewall-cmd --reload # 重载规则

Ubuntu/Debian一般用ufw：

ufw status ufw allow 80/tcp

排查到哪一步都通了，问题基本就解决了。这一套流程走下来，方向明确，不会东一榔头西一棒子。

6. 软件安装与系统更新：包管理器的那些事

6.1 包管理器的工作逻辑

Linux发行版装软件和Windows不太一样。绝大多数软件可以通过系统自带的包管理器安装，不需要去官网下载安装包。Ubuntu和Debian系用的是apt，CentOS和Rocky系用的是dnf（老版本是yum）。两者命令结构几乎一样，只是包仓库不同。

Ubuntu上是这三条命令最常用：

apt update # 刷新软件源索引 apt install 软件包名 # 安装软件 apt upgrade # 升级所有已安装的软件

注意apt update和apt upgrade的区别。update只刷新源列表，它不会装任何东西，但是如果你不先执行update就install，等于是用自己的旧索引去找新软件，往往找不到或者版本偏老。所以我一般习惯这样：

apt update && apt install nginx -y

&&表示前一条命令成功之后再执行后一条。

CentOS/Rocky就把apt替换成dnf：

dnf install nginx -y

-y是为了跳过"是否继续安装"的确认提示，不然交互式会卡在那等你按Y。

Python相关的软件包用pip安装，这个在使用云服务器部署Python应用时很常见：

pip install requests

只要你是root或虚拟环境权限足够，装上即可用。非Python环境的PHP扩展、Node.js模块也各有自己的包管理工具，逻辑类似。

6.2 软件源的常见坑

软件源报错是云服务器上非常常见的现象。如果apt update报404 Not Found，多半是你用的软件源地址过期了，尤其是老系统版本生命周期结束后，官方源会停止维护。这时候解决方式就是换源，把/etc/apt/sources.list改成可用的镜像源。云服务商一般都有自己的内网软件源，速度比公共源快很多，而且不占公网带宽，正确姿势是先去查你自己云厂商的软件源配置文档，照着修改。

换源后记得再跑一遍apt update。很多新手修改源文件时容易手抖删掉不该删的行，改之前先备份：

cp /etc/apt/sources.list /etc/apt/sources.list.bak

6.3 系统更新别乱升

关于apt upgrade，我的建议是：新买的服务器可以升到最新，跑了一段时间的业务服务器不要随意升级，升级前一定做好快照备份。原因很简单，upgrade可能会把内核、数据库驱动、PHP版本这些基石级组件一起升级，一旦某个服务不兼容新版本，线上直接故障。我自己的做法是，业务服务器固定版本，只补安全更新，改任何东西之前先打云盘快照。

如果你安装软件时遇到依赖缺失，比如提示缺少某个lib库，先别慌，apt install -f可以尝试自动修复依赖关系。再不行，就要去查具体缺的库属于哪个包，用apt install 库名补上。这种问题在实际操作中尤其常见，因为很多软件文档只写安装主程序，没有提到依赖项。

最后再分享一个小技巧

开头我说不列上百条命令，但其实还有一些命令不属于"基础"，却经常在关键时刻救命。比如历史命令记录history，你永远会感谢自己敲过的每一条命令都有记录；比如du -sh *可以快速找到哪个目录占用磁盘空间最大；再比如which nginx可以确认某个命令到底在哪个路径下，排查PATH问题时特别有用。

我个人有一个习惯：在服务器上建一个~/notes目录，把常用的命令和配置备份都放进去，出了问题先从笔记里找方案，再动手操作。这比每次遇到问题都去搜索引擎翻一遍答案高效得多。

基础命令这东西，光看永远记不住，真正上手敲几遍就熟了。从登录你的云服务器开始，把上面这条链路走一遍——摸清配置、传文件、调权限、看状态、排故障、装软件——你基本就具备了独立折腾一台Linux服务器的能力。剩下的，都是遇到问题再查、再用、再积累的过程。