企业官网建设流程全解析

先说一个常见的场景。新接一台 CentOS 7 服务器，手头有个 nginx 的 rpm 包，直接rpm -ivh装上，结果提示缺依赖，一脸懵。打开网上教程，又是让用yum install，又是让npm install，你心里肯定冒出一个问题：rpm、yum、npm 到底有什么区别？这仨名字长得像，实际上根本不是一回事。

我最早被这三者绕晕，是在一次自己折腾服务器的时候。后来在运维和前后端项目里混得久了，才算把它们的边界彻底理清楚。一句话先说结论：rpm 是红帽系 Linux 系统里的一种软件包格式；yum 是基于 rpm 之上、专门帮你解决依赖的包管理器；而 npm 是 Node.js 生态的依赖管理器，它装的是前端或 Node 项目的库，跟系统软件包完全不沾边。这篇文章就是把这套东西掰开揉碎讲清楚，顺便把三者的高频常用命令、还有我踩过的坑都整理出来。适合刚入门 Linux 的开发者、需要维护服务器的运维同学，以及前端项目里被 npm 各种报错绕晕的朋友。

1. 先把概念理清楚：rpm、yum、npm 到底各自干什么

1.1 rpm：系统的“安装包”，而不是“安装工具”

很多人误以为 rpm 是一个装软件的命令，其实 rpm 更准确的定位是一种软件包格式，后缀是.rpm，同时配套一条也叫 rpm 的命令来对它进行操作。红帽系的系统，比如 RHEL、CentOS、Rocky Linux、Fedora，以及国内的银河麒麟、统信 UOS 这类基于或兼容红帽生态的系统，沿用的都是这套 rpm 格式。

rpm 包里面装的是什么？本质上是一个已经编译好的程序，加上配置文件、启动脚本、文档这些零零碎碎的东西，打包到一起，安装时按清单把文件放到系统对应目录，然后把安装记录写进本机 rpm 数据库。这个数据库一般在/var/lib/rpm和/var/lib/dpkg里头，查询、卸载、校验全靠它。

关键点在于：rpm 本身只负责“安装、卸载、查询、校验”这些动作，它不负责拉取软件和设备之间的依赖。什么叫依赖？比如你要装 nginx，nginx 运行依赖一个叫 openssl 的库，如果系统里没有这个库，rpm 会干巴巴地告诉你“需要 libssl.so.1.1 但没有装”，然后就不动了。你得自己去找到这个库的 rpm 包，再来一轮安装。如果那个 rpm 又依赖别的包，你就陷入了经典的依赖地狱。所以，rpm 命令适合的场景是：软件包已经下载到本地、依赖关系清晰、或者你需要精细控制安装过程的离线场景。

1.2 yum：替你操心依赖的包管理器

yum 全称 Yellowdog Updater Modified，它的出现就是为了解决 rpm 依赖地狱。yum 本身不直接打包软件，它也是调用 rpm 来装包，但它在 rpm 外面包了一层“自动解析依赖”的机制。

具体怎么实现？yum 会从配置好的软件仓库（repository）里拉取软件包元数据，这些元数据描述了每个包依赖什么、提供什么。它把这些信息放到本地一个缓存里，你要装 nginx，yum 通过元数据自动算出 nginx 需要哪些依赖库，然后把这些依赖包和 nginx 一起从仓库里拉下来，逐个交给 rpm 安装。你只敲一个命令，后面一长串依赖它全包了。

yum 的仓库配置在/etc/yum.repos.d/目录下，.repo后缀的文件。比如 CentOS 7 默认有 BaseOS、AppStream 等仓库，你可以换成阿里源、腾讯源、清华源，也可以自己做一个本地 yum 源，指向挂载的光盘镜像。到了 CentOS 8 / Rocky 8 之后的版本，yum 被 dnf 取代了，dnf 是 yum 的下一代实现，性能更好，但命令用法基本一致，很多系统里你依然能直接敲yum，系统会转给 dnf。所以后面我讲到 yum 命令，你可以在新系统里直接换成 dnf，逻辑不变。

一句话：yum/dnf 是“系统级包管理器”，负责给整个操作系统安装、更新、卸载软件，并且自动解决依赖。

1.3 npm：Node.js 世界的依赖管家，跟系统包不是同一个赛道

npm 全称 Node Package Manager，是随 Node.js 一起安装的包管理器。它管理的对象是 JavaScript 项目里的第三方库和模块，比如前端框架 Vue、React，后端框架 Express，工具库 axios、lodash，构建工具 webpack、vite 等等。

为什么 npm 经常被和 yum 放在一起说？因为使用逻辑上有相似之处：都需要一个远程仓库（registry），都要通过一个配置文件来声明依赖，都能自动处理依赖关系。npm 的仓库默认地址是https://registry.npmjs.org/，国内一般会用镜像源如https://registry.npmmirror.com/来加速，也就是常说的“npm 国内镜像源”。依赖声明写入项目根目录的package.json文件，实际安装的文件放在node_modules目录。

注意一个容易混淆的点：npm 装的是 Node 模块，是给 JavaScript 项目用的，不是给操作系统用的。你不能用npm install nginx来装一个系统软件，也不能用yum install axios来给 Node 项目装依赖。这俩生态完全隔离，一个是系统级，一个是项目级。

1.4 一句话对比表格

这个表格建议收藏，想不明白时拿出来看一眼。

2. rpm 命令实战：低频但牵一发动全身

2.1 查询：快速判断“装了没”“文件归谁”

rpm 用的最多的是查询，而不是安装。我日常排查服务器问题时，第一件事就是确认某个软件到底装没装、装的是什么版本、有哪些文件、这些文件属于谁。

# 查询某个软件包是否安装 rpm -q nginx # 列出所有已安装且名字包含 nginx 的包 rpm -qa | grep nginx # 查看指定包的详细信息，包括版本、发布时间、安装时间 rpm -qi nginx # 列出这个包安装后都释放了哪些文件 rpm -ql nginx # 反查：系统里某个文件 /usr/bin/xx 是哪个 rpm 包安装出来的 rpm -qf /usr/bin/nginx

rpm -qa | grep是我在捣鼓环境时敲得最多的命令。比如记不清机器上到底有没有装过 openssl-devel，一句rpm -qa | grep openssl直接看输出结果。rpm -qf也很实用，当你不知道/etc/nginx/nginx.conf这个文件是谁生成的，用它反查一下就能定位到来源。

2.2 安装：rpm -ivh 和它的两个危险开关

安装的完整命令是：

rpm -ivh package.rpm

参数拆解：-i是 install，-v是显示详细信息，-h用#号显示安装进度。平时我习惯连写成-ivh，如果只想要安静安装，也可以只写-i，但看不到进度，等半天不知道卡没卡，所以还是建议加上-vh。

如果这个包之前装过旧版本，可以用升级方式：

rpm -Uvh package.rpm

-U代表 upgrade，如果有旧包会先卸载旧包再装新包，没有旧包则直接安装。-Fvh则不同，-F是 freshen，只在有旧包的时候才升级，没有旧包就跳过，这在批量更新已装包时比较有用。

这里必须重点说两个危险参数：--nodeps和--force。当 rpm 报缺失依赖时，很多人第一反应是加--nodeps忽略依赖，强装上去，然后程序运行时报段错误或缺少动态库。我的建议是：能不用就不要用。特别在生产环境，缺依赖说明系统里确实没有对应库，强装等于埋雷。但也有例外，比如你的系统里已经存在某个库的更新版本，rpm 因为把版本限制死而误判缺失，这时候加--nodeps强装是合理的。--force通常配合--nodeps一起出现，作用是强制覆盖已安装的文件，我一般只在打包自己的安装包、明确知道要覆盖哪些文件时才用它。

2.3 卸载与校验：清干净和不被动过手脚

卸载命令：

rpm -e nginx

-e是 erase。如果卸载时报“某个依赖这个包”而无法删除，说明系统里还有其他软件在依赖它。这时候不要慌，先像上面那样用rpm -q看看到底是谁在依赖，确认无误后再考虑是否删除。

另有一个场景比较特殊：某些服务被攻击或误操作后，配置文件被改动，你可能需要快速校验。rpm 提供了校验功能：

rpm -V nginx

-V会拿当前系统文件跟 rpm 数据库里记录的原始信息比对。如果输出结果为空，说明文件都对。若有输出，每一行开头的字母代表不同的变更类型，比如S表示文件大小变了，M表示权限变了，5表示 MD5 校验不通过。检查被改动的文件是否被篡改时，这个命令就是利器。

2.4 实战场景：离线安装 openssh-10.3 的 rpm 包

最近网上很多人搜 openssh-10.3 rpm 包下载，这个场景特别典型：线上服务器扫出来 openssh 有安全漏洞，需要升级，但默认 yum 源里的 openssh 版本很旧，你只能去外部渠道下载新版本 rpm 包，然后在内网离线安装。

下载到本地后，我的习惯是先做一轮依赖检查：

rpm -qpR openssh-xxx-10.3.rpm

-q是查询，-p是对尚未安装的 rpm 包文件操作，-R是列出依赖。这条命令会告诉你这个包要求哪些依赖库。接下来逐个确认系统里有没有：

rpm -q openssl-libs

最后再rpm -Uvh openssh-xxx-10.3.rpm安装。如果升级 openssh-server 这种敏感服务，安装前千万要确认 sshd 的配置备份好了，否则一旦重启失败，你连不上服务器就只能去机房或带外管理口操作了。

3. yum/dnf 命令实战：日常装系统的真正主角

3.1 安装、卸载、更新全套命令

yum 的命令规则很好记，核心就几个动作。

# 搜索软件包 yum search nginx # 查看软件仓库列表 yum repolist # 查看某个包的详细信息 yum info nginx # 安装 yum install -y nginx # 卸载 yum remove nginx # 更新指定包 yum update nginx # 更新所有可更新包 yum update -y # 只下载不安装 yum install --downloadonly --downloaddir=/opt/packages nginx # 清理缓存 yum clean all # 列出已安装的包 yum list installed

-y参数的意思是全自动回答 yes，所有交互提示都跳过。我建议脚本里和交互式命令行里都加上，不然半夜远程装包，一个“Is this ok [y/N]:”卡住，你睡着了，它等着，很崩溃。

yum search适合你只知道大概名字、不确定准确包名的时候。比如你想装图形界面的文本编辑器，敲yum search gedit，就把所有包名和描述里带 gedit 的包都列出来。yum info可以看版本、大小、仓库来源，装之前瞄一眼可以避免装错包。

3.2 更新排除内核与 openssh 这类敏感包

生产环境最怕什么？最怕手贱yum update -y把所有包全更新了，结果内核升级后驱动不兼容，或者 openssl 版本变化导致某些服务起不来。更新策略我的经验是：默认不更新内核，只更新业务相关的安全补丁，且更新前备份配置。

排除内核更新用这个：

yum update -y --exclude='kernel*'

--exclude是排除指定通配符的包，这样 yum 在更新时就会跳过所有名字以 kernel 开头的包。同理，如果想固定 openssh 不升级，写--exclude='openssh*'。

还有yum update和yum upgrade的区别。老版本 yum 里二者行为基本一致，都是更新所有可更新包；在新版 dnf 里upgrade是默认的更新行为，update则是upgrade的别名。习惯上生产环境建议用yum update --exclude='kernel*'，别让它轻易动内核。

升级完 openssh 那类网络服务，一定要记住重启 sshd 之前先检查配置：

sshd -t

如果这个检查都没过，千万别重启服务，否则 ssh 会直接断开，而你还没法通过 ssh 重新连上——这就是经典的“自己把自己锁在门外”事故。

3.3 把 yum 源换成阿里源：精确到版本的坑

CentOS 7 时代，最常见的操作是换阿里源。核心步骤是备份系统自带的.repo文件，然后下载阿里的官方仓库文件。

# 备份 mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak # 下载阿里源（CentOS 7 为例） curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo # 清理缓存并重新生成 yum clean all yum makecache

这里有几个坑。第一，CentOS 8 及以后的版本，系统默认仓库文件多了 AppStream、PowerTools 等，阿里源也有对应的Centos-8.repo，注意区分下载。第二，CentOS 7、CentOS 8、CentOS 9 的源文件 URL 不同，不要拿 7 的源文件配置到 9 上。第三，如果你用的是 redhat 6.5 这种老版本，或者银河麒麟这类国产系统，网络上的通用源不一定兼容，最好的做法是优先用系统自带的源，或者官方源镜像。

换完源后，做一次yum repolist确认仓库生效，看到输出里有可用的仓库包数量，再开始装东西。

CentOS 7 已经 EOL 之后，网上很多源也在陆续失效，如果你手头还有 7 在跑，建议尽快找替代方案或把源切到 vault 归档目录，不然就会遇到“errors during downloading metadata”这种下载元数据失败的问题。

3.4 本地 yum 源搭建：离线环境全靠它

内网环境里没有外网，又要给一批服务器装软件，最快的方法就是用系统镜像盘做本地 yum 源。这也是 CentOS 7 本地 yum 源搭建、Linux 配置本地 yum 源实验目的里最常讨论的操作。

先挂载镜像：

mkdir -p /mnt/cdrom mount /dev/cdrom /mnt/cdrom

然后创建本地仓库文件：

vi /etc/yum.repos.d/local.repo

内容如下：

[local] name=Local Repository baseurl=file:///mnt/cdrom enabled=1 gpgcheck=0

保存后执行：

yum clean all yum makecache yum repolist

如果repolist里能看到 local 仓库，说明本地源生效，可以开始离线装包了。

这里有几个容易踩的细节。第一，CentOS 8 / Rocky 8 的光盘镜像在挂载后，软件包实际分布在/mnt/cdrom/BaseOS和/mnt/cdrom/AppStream两个目录，直接写baseurl=file:///mnt/cdrom是装不上的，要分别建两个仓库：

[BaseOS] name=BaseOS baseurl=file:///mnt/cdrom/BaseOS enabled=1 gpgcheck=0 [AppStream] name=AppStream baseurl=file:///mnt/cdrom/AppStream enabled=1 gpgcheck=0

第二，实验做完别忘了卸载镜像，有的同学搞完直接重启，结果服务器卡在“No bootable device”，因为光盘还插在光驱里且引导顺序靠前。第三，gpgcheck=0表示跳过 GPG 密钥校验，离线环境一般没问题，但如果包来源不明，建议保留gpgcheck=1并配置gpgkey。

额外提醒：本地源的包版本一般偏旧，因为镜像盘的软件包在发行时就已经固定了，之后的安全更新不会包含在内。所以本地源适合解决“能不能装上”的问题，升级安全补丁还是得走外网源。

3.5 下载 rpm 包到本机，批量分发

有时候你不是要在本机装，而是要一次性给多台服务器装同一批软件。这时候直接把 rpm 包下载下来，拷到别的机器上再用 rpm 安装，比每台机器都走一次网络源快得多。

# 方法一：yum 的 downloadonly 插件 yum install --downloadonly --downloaddir=/opt/packages nginx # 方法二：yumdownloader 工具 yum install -y yum-utils yumdownloader --resolve --destdir=/opt/packages nginx

重点说下yumdownloader --resolve，--resolve意思是把依赖包也一起下载下来。只写yumdownloader nginx的话，它只会下载 nginx 本体，依赖库还得另想办法。这个细节非常关键，离线场景下如果依赖不全，到对方机器上一样会报缺依赖。

把/opt/packages目录里的 rpm 全部安装的批量命令是：

rpm -Uvh /opt/packages/*.rpm

注意：rpm -Uvh处理同目录多个包时，会先统一分析依赖关系再逐个安装，所以即使包之间互相依赖，也能自动判断顺序，比手动逐个敲要稳。

4. npm 命令实战：前端和后端 Node 项目的日常

4.1 初始化、安装、卸载、查看一条龙

npm 的核心工作对象是package.json。进入一个项目目录，第一次执行npm init会让你填写项目名、版本、入口文件等一堆信息，嫌麻烦就直接：

npm init -y

-y表示使用默认值快速生成package.json，后续再手动改里面的字段。

安装依赖是最常用的操作：

# 安装项目依赖并写入 dependencies npm install axios # 简写形式 npm i axios # 安装开发依赖，写入 devDependencies npm install -D typescript # 全局安装 npm install -g nodemon # 安装 package.json 里所有依赖 npm install

dependencies是项目运行时需要的依赖，比如 Express、axios；devDependencies是开发和构建阶段需要、但生产环境可以不要的工具，比如 typescript、webpack、eslint。这个区分除了规范意义，也直接影响npm install --production的行为——生产环境只装dependencies，不装开发依赖，能省下不少空间和装包时间。

卸载：

npm uninstall axios npm uninstall -g nodemon

查看已安装的包：

npm list npm list --depth=0

npm list --depth=0只显示项目直接依赖，不列间接依赖，输出很清爽。查看某个包的最新版本和相关信息：

npm view axios npm view axios version

npm view axios version会直接输出云端最新版本号，比如 1.7.2，方便你判断是否要升级。

4.2 换镜像源提速

npm 默认仓库在国外，国内网络经常慢得离谱，卡在npm ERR! network或者等半天进度条不动。更有效的手段是配置国内镜像源。现在主流推荐的是淘宝 npm 镜像：

# 查看当前镜像源 npm config get registry # 设置为淘宝镜像源 npm config set registry https://registry.npmmirror.com/ # 设置回官方源 npm config set registry https://registry.npmjs.org/

除了全局配置，也可以在项目根目录新建.npmrc文件，写入：

registry=https://registry.npmmirror.com/

这种方式只对当前项目生效，不会影响其他项目，我在公司项目里更推荐这种，避免把开发者机器上的全局源改成乱七八糟的地址。

如果你不想改配置，也可以临时指定源：

npm install --registry=https://registry.npmmirror.com/

缺点是每次都要打长参数，适合偶尔用一次的场景。

4.3 Windows 下 npm 的两个经典报错

Windows 系统下 npm 的报错特别经典，一个是“npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本”，另一个是“npm : 无法将“npm”项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。

第一个报错是因为 PowerShell 的执行策略默认是 Restricted，禁止运行.ps1脚本，而 npm 在 PowerShell 里执行时走的是 npm.ps1。解决办法是用管理员身份打开 PowerShell，执行：

Set-ExecutionPolicy RemoteSigned

执行后选Y确认。RemoteSigned的意思是本地脚本可以运行，从网上下载的脚本必须经过签名才能运行，兼顾安全和便利。如果不想修改全局策略，也有另一种方法：在cmd命令行里跑 npm 命令，因为 cmd 不检查 PowerShell 执行策略，完全绕开这个限制。

第二个报错“无法识别为 cmdlet”通常是 Node.js 没装好或者环境变量PATH里没有 Node.js 的安装路径。先确认安装目录，然后手动把 Node.js 的安装路径（比如C:\Program Files\nodejs\）加进系统环境变量Path里。添加后必须重新打开一个命令行窗口，环境变量才会生效，这是新手最容易忽略的一点。

还有一个小问题是 npm 安装时频繁输出的 deprecation 警告，比如：

npm warn deprecated node-domexception@1.0.0: use your platform's native DOMException instead

看到这种npm warn不要太担心，它提示的是某个间接依赖的包已被作者标记作废旧版本，可能有安全隐患或功能缺陷。多数情况下这只是旧的传递依赖在提醒你该升级了，如果项目能正常构建，可以暂时不管。但如果警告指向的是重要依赖，建议用npm outdated看一下有哪些包可以更新，然后针对性升级。

4.4 发布 npm 包的基本流程

自己写的工具库想发布到 npm 仓库供团队使用，流程不复杂。

# 1. 首次登录 npm adduser # 2. 已有账号则登录 npm login # 3. 修改版本号（patch 是补丁版本，minor 是小版本，major 是大版本） npm version patch # 4. 发布 npm publish

npm version patch会直接把package.json里的版本号从 1.0.0 改成 1.0.1，并提交一个 git tag。minor把 1.0.1 变成 1.1.0，major变成 2.0.0。

发布之前最好确认package.json里的name在 npm 仓库里没有被占用，以及files字段定义好了要发布哪些文件，不然把自己项目里的源码、测试文件、配置文件全发出去了，别人下载后看到一堆杂乱文件，体验很差。我在files里通常只放发布必需的dist目录和 README。

5. 三者界限与常见问题速查

5.1 什么时候该用哪个：从实际场景出发

第 1 节的表格是从技术角度对比，这里我换个角度，从实际场景出发讲怎么选。

如果你是系统管理员，要在 CentOS/Rocky 上装一个系统服务，比如 Nginx、MySQL、Docker，优先用yum。仓库里有现成包，依赖自动处理，卸载也干净。只有在离线环境、或软件仓库里没有你需要的特定版本、或者你自己打包了 rpm 需要测试时，才退到rpm层面操作。

如果你是前端或 Node 后端开发者，要给项目装 JS 库，就必须用npm，并且只在项目里用npm install管理依赖，不要试着用yum给 Node 项目装模块。同理，系统管理员也不要看到npm就以为是安装工具，它能装的东西跟系统毫无关系。唯一会交叉的场景是：你需要在系统里安装 Node.js 本身，这时候用yum install nodejs或下载官方二进制包，装好之后，npm只是 Node.js 自带的一个命令。

判断方法很简单：系统级程序用 yum/rpm，项目级 JS 库用 npm。分清这个，基本就不会混了。

5.2 高频报错与排查方法汇总

这张表里每个问题都是实际踩过或帮同事排查过的。排查思路其实就是先确认“是不是网络问题、是不是配置问题、是不是权限问题”，再依次排除。比如 yum 报下载元数据失败，先 ping 一下源域名通不通；通的话再检查 URL 是否 404；还不行就清理缓存重来。别一上来就找重装系统这种终极大招。

5.3 关于“Artisan 版本”的补充说明

这里补充一点：有时候你会发现同样都是 rpm 包，有的叫.rpm，有的叫.src.rpm。.rpm是编译好的二进制包，直接安装就能用；.src.rpm是源代码包，装进去的是源码和编译脚本，需要用rpmbuild重新编译成二进制包再安装。正常使用场景下我们下载的都是二进制.rpm，看到.src.rpm不用下载，那是给维护者用的。

还有 CentOS 7 之后，yum命令在很多新旧系统里还能互相兼容，但在纯 dnf 系统上，部分老命令像yum repolist照样能用，这就导致很多人根本分不清自己在用哪个。我的建议是：新系统直接养成敲dnf的习惯，老系统继续用yum，两者在这个层面的差异对你的实际经验积累没有影响。

6. 最后再分享一点个人心得

这三样工具我用了很多年，最大的体会是：别把它们当竞争对手，它们是不同层次的东西。rpm 是单机离线安装的保底方案，yum/dnf 是红帽系系统的软件入口，npm 是 JavaScript 生态的依赖管家。它们之所以容易被放在一起讨论，是因为命令行风格相似、时间长了大家习惯了“装软件就是用这类命令”的直觉。

我在实际项目里长期保持的习惯是：新装一台服务器，先想清楚“这台机器有没有外网？如果有，优先配好 yum 源再用 yum；如果没有，准备好镜像盘或本地源再动工；要开发 Node 项目，就专心用 npm”。更新策略上一律保守，生产环境不追新，yum update -y --exclude='kernel*'是我的默认动作。npm 这边则坚持用package-lock.json锁定依赖版本，避免某天某依赖升级后悄悄出问题。

如果这篇文章能帮你少走一次弯路，那这半小时就没白折腾。实际操作中遇到问题，多试试man rpm、man yum、npm help，命令文档里写的永远比二手教程细。