1. 项目概述为什么在 CentOS 8 上装 Node.js 是个“看似简单、实则踩坑密集”的活儿Node.js 在 CentOS 8 上的安装远不是敲几行命令就能一劳永逸的事。我从 2019 年 CentOS 8 刚发布时就在生产环境里反复折腾过它到 2024 年维护着十几台遗留 CentOS 8 服务器几乎每个月都会遇到新同事因为 Node.js 安装问题卡住半天——不是nvm ls报错no installations recognized就是dnf install nodejs装出来一个连npm -v都报错的半残版本更别提那些failed to search for file: cannot update repo appstream: cannot prepare的仓库错误直接让整个安装流程卡死在第一步。这些不是偶然而是 CentOS 8 独特的软件生命周期设计、AppStream 模块化仓库机制、以及 Node.js 版本演进节奏三者激烈碰撞的结果。它不像 Ubuntu 那样默认提供较新的 LTS 版本也不像 macOS 那样有 Homebrew 这种高度自动化的包管理器CentOS 8 的核心逻辑是“稳定压倒一切”所以它的 AppStream 仓库里默认只打包了经过 Red Hat 全面测试的 Node.js 10 和 12后期追加了 14 和 16而这些版本早在 2023 年就已全部进入 EOLEnd of Life状态不再接收安全更新。这意味着如果你按官方文档照搬dnf install nodejs你得到的很可能是一个存在已知高危漏洞、且无法运行现代前端框架如 Vue 3.4、Next.js 14或后端服务如 NestJS v10的“古董版” Node.js。真正的难点不在于“怎么装”而在于“装哪个版本、用什么方式装、装完怎么验证它真的能干活”。这背后涉及三个关键决策点是信任系统包管理器dnf的“稳定”承诺还是转向开发者友好的nvm实现多版本共存与快速切换是手动编译源码追求极致可控还是借助 NodeSource 提供的第三方仓库获取主流 LTS 版本每一种选择都对应着不同的运维成本、安全风险和团队协作效率。尤其对于正在将老旧 PHP 或 Java 应用逐步迁移到 Node.js 微服务架构的团队来说一个配置错误的 Node.js 环境可能让整个 CI/CD 流水线在npm ci步骤就失败导致上线计划延误。所以这篇内容不是一份简单的“步骤清单”而是我过去五年在金融、电商、SaaS 类 CentOS 8 生产环境中踩过所有典型坑之后总结出的一套可复用、可审计、可交接的 Node.js 安装方法论。它会告诉你当dnf报错仓库无法更新时真正该检查的是/etc/yum.repos.d/下哪些 repo 文件被意外禁用了当nvm install 18.20.2失败提示“not yet released”你需要知道这是 nvm 的缓存机制出了问题而不是网络或版本号写错了当你发现node -v显示正常但npm -v报错“command not found”那大概率是 PATH 环境变量里漏掉了 npm 的安装路径。这些细节才是决定一次安装是“5 分钟搞定”还是“耗掉整个下午”的分水岭。2. 核心方案对比与选型逻辑dnf、NodeSource、nvm 三大路径的实战权衡在 CentOS 8 上部署 Node.js目前主流有三条技术路径系统原生dnf、第三方NodeSource仓库、以及开发者向的nvmNode Version Manager。它们不是简单的“谁更好”而是各自服务于完全不同的运维场景和团队能力模型。我不会笼统地说“推荐用 nvm”而是把每条路的底层逻辑、适用边界、以及我亲手踩过的具体坑掰开揉碎讲清楚。2.1 dnf 方式Red Hat 官方背书的“稳定幻觉”dnf install nodejs是最符合 CentOS 哲学的安装方式。它从 Red Hat 维护的 AppStream 仓库拉取 RPM 包所有依赖关系由 DNF 自动解析安装过程干净利落且与系统其他组件如 OpenSSL、glibc版本严格对齐理论上杜绝了 ABI 兼容性问题。我在某家银行的核心交易网关项目中就曾强制要求所有中间件必须走dnf安装理由是审计合规——任何第三方仓库或手动编译的二进制文件都需要额外的安全白名单审批流程耗时数周。但这种“稳定”是有代价的。CentOS 8 的 AppStream 仓库策略是“冻结快照”即每个 minor 版本如 8.4、8.5发布时其 AppStream 内容就被固定下来后续只接受安全补丁不升级主版本。因此即使你执行dnf update也永远无法从仓库里获得 Node.js 18 或 20。我查过 RHEL 8.6 的官方文档其 AppStream 中最高支持的 Node.js 版本是 16.14.2而这个版本在 2024 年 9 月已正式 EOL。更致命的是dnf安装的 Node.js 是“系统级”的意味着所有用户共享同一个版本无法为不同项目指定不同 Node.js 运行时。当你需要同时维护一个基于 Express 4.x兼容 Node.js 12的老后台和一个基于 Fastify 4.x要求 Node.js 18的新 API 网关时dnf就成了最大的枷锁。此外dnf安装的 npm 是与 Node.js 绑定的版本通常滞后于上游比如dnf装的 Node.js 16.14.2 自带 npm 8.5.5而社区最新稳定版已是 8.19.2后者修复了多个与package-lock.json解析相关的严重 bug。所以dnf方式只适合一种场景你的应用对 Node.js 版本无特殊要求且整个服务器上只运行一个 Node.js 服务同时你所在的组织对“第三方软件源”有严格的合规红线。否则它带来的“稳定”很可能是虚假的因为你正在运行一个已停止维护的、存在已知漏洞的运行时。2.2 NodeSource 仓库平衡稳定与现代性的折中之选NodeSource 是由 Node.js 社区核心成员创立的第三方仓库专门为 RHEL/CentOS/Fedora 等发行版提供官方 Node.js 二进制包。它的价值在于它绕过了 Red Hat 的版本冻结策略直接提供 Node.js 官方发布的 LTS长期支持版本如 18.xGallium、20.xIron和最新的 22.xRome。安装过程依然使用dnf保证了 RPM 包管理的完整性和可审计性。我给一家跨境电商 SaaS 公司搭建 CI/CD 构建节点时就选择了 NodeSource。原因很简单他们的前端团队每天都在用 Vue 3.3 Vite 4.x 开发这些工具链最低要求 Node.js 16.14而dnf默认提供的 14.x 会直接导致vite build命令崩溃。通过curl -fsSL https://rpm.nodesource.com/setup_lts.sh | sudo bash -导入仓库后dnf install nodejs就能装上 Node.js 18.20.2且npm版本同步更新到 10.7.0完美匹配 Vite 的需求。更重要的是NodeSource 的包是“独立于系统”的它会把 Node.js 安装到/usr/bin/node而不会覆盖/usr/lib64/node_modules下的系统模块避免了与dnf管理的其他软件冲突。但这条路也有它的暗礁。最大的问题是仓库地址的时效性。NodeSource 的 setup 脚本会根据你的系统版本cat /etc/centos-release自动选择对应的 RPM 仓库 URL。如果脚本里的 URL 过期了比如 NodeSource 停止维护了某个旧版仓库你就会遇到Failed to download metadata for repo nodesource的错误。我遇到过一次是因为脚本里还引用着https://rpm.nodesource.com/pub_16.x/el/8/x86_64/这个已废弃的路径而正确的应该是https://rpm.nodesource.com/pub_18.x/el/8/x86_64/。解决办法不是瞎猜而是去 NodeSource 官网的 GitHub 仓库github.com/nodesource/distributions查看setup.sh的最新源码或者直接手动编辑/etc/yum.repos.d/nodesource-el8.repo把baseurl改成当前有效的路径。另一个小坑是NodeSource 安装的 Node.js 是全局单版本的虽然比dnf的版本新但依然不支持多版本共存。如果你的服务器上要跑多个需要不同 Node.js 版本的微服务它就力不从心了。2.3 nvm 方式开发者自由度的终极解决方案nvmNode Version Manager是我个人在 CentOS 8 上进行日常开发和调试时的绝对首选。它不是一个系统级的包管理器而是一个 Bash 脚本它的工作原理是在用户主目录下~/.nvm创建一个独立的 Node.js 运行时沙箱并通过动态修改PATH环境变量让 shell 在执行node或npm命令时优先找到~/.nvm/versions/node/v18.20.2/bin/下的可执行文件。这带来了三个无可替代的优势第一真正的多版本共存。你可以同时安装nvm install 16.20.2、nvm install 18.20.2、nvm install 20.15.0然后用nvm use 18或nvm use 20在秒级内完成切换甚至可以为每个项目目录设置.nvmrc文件实现“进入目录自动切换版本”。第二极高的灵活性和可控性。nvm install默认从https://nodejs.org/dist/下载官方预编译二进制包这意味着你能装上 Node.js 官网发布的任何一个版本包括最新的 Current 版本如 22.x和尚未被任何 Linux 发行版仓库收录的 RCRelease Candidate版本。第三零系统侵入性。所有文件都存在于用户目录下卸载只需rm -rf ~/.nvm不会留下任何系统级残留非常适合在共享服务器或受限权限的生产环境中进行临时调试。然而“自由”也意味着“责任”。nvm的最大陷阱在于它的“用户级”属性。它只对当前用户的 shell 会话生效。如果你用sudo执行一个 Node.js 脚本或者用systemd启动一个服务systemd的环境变量里根本就没有nvm的路径所以node命令会找不到。我曾经在一个客户现场花了整整一天排查一个systemd服务启动失败的问题最后发现根源就是服务的ExecStart指令里写的node app.js而systemd的PATH里没有~/.nvm/versions/node/v18.20.2/bin。解决方案是在systemd服务文件里显式指定EnvironmentPATH/home/deploy/.nvm/versions/node/v18.20.2/bin:/usr/local/bin:/usr/bin:/bin。另一个常见问题是nvm ls报错no installations recognized。这几乎 100% 是因为nvm的初始化脚本没有被正确加载。nvm的安装脚本curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash会在~/.bashrc末尾追加一段代码用于source~/.nvm/nvm.sh。但如果用户用的是zsh或者~/.bashrc里有return语句提前退出这段代码就不会执行。此时你必须手动检查~/.bashrc是否包含export NVM_DIR$HOME/.nvm和[ -s $NVM_DIR/nvm.sh ] \. $NVM_DIR/nvm.sh这两行并确保它们在文件末尾且未被注释。总结来说nvm是给“人”用的dnf是给“系统”用的NodeSource是给“需要现代版本但又不敢脱离 RPM 体系”的中间派用的。你的选择本质上是你对“控制权”、“合规性”和“便利性”三者权重的排序。3. 实操全流程详解从环境诊断到生产就绪的每一步现在我们进入最硬核的部分手把手带你完成一次从零开始、可落地、可复现的 Node.js 安装。我会以nvm方式为主轴因为它覆盖了最广泛的使用场景同时也会穿插dnf和NodeSource的关键操作作为备选。整个过程不是简单的命令罗列而是每一步都解释“为什么要这么做”、“不做会怎样”、“如何验证它做对了”。3.1 环境诊断与前置准备别急着敲命令先看清你的系统底牌在 CentOS 8 上安装任何软件之前第一步永远是“摸清家底”。很多安装失败根源不在安装过程本身而在于对系统状态的误判。请打开终端依次执行以下命令并仔细阅读输出# 1. 确认系统版本和架构这是所有后续操作的前提 cat /etc/centos-release # 输出应为CentOS Linux release 8.5.2111 或类似。注意CentOS 8 Stream 和 CentOS 8 Classic 的仓库配置完全不同不能混用。 # 2. 检查当前启用的 DNF 仓库特别是 AppStream dnf repolist --enabled | grep -E (appstream|baseos|powertools) # 你应该看到至少 appstream 和 baseos 两个仓库处于 enabled 状态。如果 appstream 不在列表里说明仓库被禁用了dnf install 必然失败。 # 3. 检查 DNS 解析是否正常这是下载远程资源的基础 nslookup nodejs.org # 如果返回 server cant find nodejs.org说明你的服务器 DNS 配置有问题需要先修复 /etc/resolv.conf。 # 4. 检查磁盘空间Node.js 编译或下载需要几百 MB 空间 df -h /home # nvm 默认安装在 /home/username/.nvm确保 /home 分区有足够空间建议 2GB。 # 5. 检查 GCC 和基础编译工具虽然 nvm install 默认用二进制包但某些情况下会回退到源码编译 dnf groupinstall Development Tools dnf install gcc-c make提示dnf repolist --enabled是诊断failed to search for file: cannot update repo appstream: cannot prepare错误的黄金命令。如果appstream不在列表里不要慌这不是系统坏了而是它的 repo 文件被禁用了。你需要检查/etc/yum.repos.d/目录下的centos-appstream.repo文件找到[appstream]这一节确认enabled1这一行没有被注释掉即前面没有#号。如果被注释了用sudo vi /etc/yum.repos.d/centos-appstream.repo打开删掉#保存退出再运行dnf clean all dnf makecache问题就解决了。这个操作我做过不下五十次它是 CentOS 8 系统管理员的肌肉记忆。3.2 nvm 安装与初始化让 Bash 认识你的新管家nvm的安装本身非常简单但初始化的“最后一公里”却最容易出错。我们采用最稳妥的手动方式避开自动脚本可能带来的路径问题。# 1. 使用 curl 下载并执行官方安装脚本此脚本会创建 ~/.nvm 目录并下载最新版 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # 2. 此时nvm 已经下载到 ~/.nvm但你的当前 shell 还不知道它。你需要手动 source 它。 # 注意这里不是执行 ~/.nvm/nvm.sh而是 source 它这样才能把函数加载到当前 shell 环境。 source ~/.nvm/nvm.sh # 3. 验证 nvm 是否可用 nvm --version # 输出应为0.39.7 # 4. 关键步骤为了让 nvm 在每次新开 shell 时都自动生效必须把它写入你的 shell 配置文件。 # 如果你用的是默认的 bash请编辑 ~/.bashrc echo export NVM_DIR$HOME/.nvm ~/.bashrc echo [ -s $NVM_DIR/nvm.sh ] \. $NVM_DIR/nvm.sh ~/.bashrc echo [ -s $NVM_DIR/bash_completion ] \. $NVM_DIR/bash_completion ~/.bashrc # 5. 重新加载配置使更改立即生效 source ~/.bashrc # 6. 最终验证打开一个全新的终端窗口或执行 bash 进入新子 shell然后输入 nvm list # 输出应为- system (default) 或类似的空列表表示 nvm 初始化成功。注意source ~/.bashrc和source ~/.nvm/nvm.sh是两回事。前者是加载你的用户环境配置后者是加载nvm的核心函数。很多人只做了第一步忘了第二步结果nvm命令在新终端里依然不可用。另外nvm的list命令显示system指的是系统自带的node如果有的话这很正常不用管它。3.3 Node.js 版本安装与验证不只是nvm install更要懂它在做什么现在nvm已经就位我们可以开始安装 Node.js 了。但请记住nvm install不是一个黑盒它背后是一系列精确的网络请求和文件操作。# 1. 查看所有可用的 Node.js 版本这会从 https://nodejs.org/dist/ 获取最新列表 nvm ls-remote # 2. 安装一个稳定的 LTS 版本例如 18.20.2Gallium nvm install 18.20.2 # 3. 安装完成后nvm 会自动将该版本设为当前使用版本。你可以用以下命令确认 node -v # 输出v18.20.2 npm -v # 输出10.7.0这是 Node.js 18.20.2 自带的 npm 版本 # 4. 重要验证 npm 的功能是否完整。创建一个临时目录测试 mkdir /tmp/nvm-test cd /tmp/nvm-test npm init -y npm install lodash4.17.21 ls node_modules/lodash/package.json # 如果能看到该文件说明 npm 的下载、解压、链接功能全部正常。nvm install 18.20.2这条命令的背后nvm会做以下事情首先它会拼接出下载 URLhttps://nodejs.org/dist/v18.20.2/node-v18.20.2-linux-x64.tar.xz然后用curl下载这个约 30MB 的压缩包接着用tar解压到~/.nvm/versions/node/v18.20.2/目录最后创建符号链接~/.nvm/alias/default - v18.20.2和~/.nvm/current - v18.20.2。所以当你看到nvm install卡住时90% 的概率是网络问题。此时你可以手动下载那个.tar.xz文件放到~/.nvm/tmp/目录下再运行nvm install 18.20.2nvm会自动检测到本地文件并跳过下载步骤。这也是为什么nvm install 24.16.0会报错is not yet released——因为https://nodejs.org/dist/v24.16.0/这个 URL 根本不存在Node.js 官网还没发布这个版本。nvm的ls-remote命令只是列出它能“看到”的版本而这个列表的源头就是官网的/dist/目录。3.4 生产环境部署让 systemd 服务也能用上 nvm 管理的 Node.jsnvm在交互式 shell 中工作完美但生产环境的服务通常由systemd管理。systemd的环境是隔离的它不会读取你的~/.bashrc所以必须显式地告诉它node命令在哪里。# 1. 创建一个 systemd 服务文件例如 /etc/systemd/system/myapp.service sudo vi /etc/systemd/system/myapp.service在文件中填入以下内容请根据你的实际路径修改[Unit] DescriptionMy Node.js Application Afternetwork.target [Service] Typesimple Userdeploy WorkingDirectory/home/deploy/myapp # 关键显式设置 PATH把 nvm 的 bin 目录放在最前面 EnvironmentPATH/home/deploy/.nvm/versions/node/v18.20.2/bin:/usr/local/bin:/usr/bin:/bin # 关键显式指定 node 的绝对路径避免 PATH 查找失败 ExecStart/home/deploy/.nvm/versions/node/v18.20.2/bin/node /home/deploy/myapp/app.js Restarton-failure RestartSec10 [Install] WantedBymulti-user.target# 2. 重载 systemd 配置并启动服务 sudo systemctl daemon-reload sudo systemctl start myapp sudo systemctl status myapp # 观察输出确认状态为 active (running)且日志里没有 command not found 错误。 # 3. 设置开机自启 sudo systemctl enable myapp实操心得我曾经在一个高并发的实时聊天服务中因为忘记在Environment里添加NODE_ENVproduction导致应用在development模式下运行内存泄漏严重三天后 OOM Killer 就干掉了进程。所以强烈建议在Environment里加上NODE_ENVproduction和TZAsia/Shanghai或其他你的时区这是生产环境的标配。4. 常见问题与排查技巧实录那些让你抓狂的报错其实都有标准解法在 CentOS 8 上安装 Node.js有一套高频出现的“经典报错组合拳”。它们就像老朋友一样每隔几个月就会来拜访一次。我把它们整理成一张速查表并附上我亲测有效的解决方案。4.1 “nvm ls 报错 no installations recognized” —— 最常见的幻觉这个问题的根源99% 都是nvm的初始化脚本没有被加载。nvm的核心是一个 Bash 函数库如果这个库没被source进当前 shell那么nvm命令本身都不存在更别说ls了。排查步骤操作命令预期输出说明1. 检查 nvm.sh 是否存在ls -l ~/.nvm/nvm.sh-rwxr-xr-x 1 user user ... /home/user/.nvm/nvm.sh如果报No such file or directory说明nvm安装失败需重装。2. 检查 .bashrc 是否包含 source 行grep -n nvm.sh ~/.bashrc123:[ -s $NVM_DIR/nvm.sh ] \. $NVM_DIR/nvm.sh如果没有输出说明初始化代码没写入需手动添加。3. 检查当前 shell 是否是 bashecho $SHELL/bin/bash如果是/bin/zsh则需要把source行写入~/.zshrc。4. 强制重新加载source ~/.bashrc nvm list- v18.20.2这是最终验证。注意nvm list和nvm ls是同义词都可以用。但nvm list更符合直觉。4.2 “failed to search for file: cannot update repo appstream: cannot prepare” —— 仓库失联这个错误表明 DNF 无法连接到appstream仓库。它和网络无关纯粹是仓库配置问题。可能原因解决方案详细说明仓库被禁用sudo vi /etc/yum.repos.d/centos-appstream.repo将[appstream]下的enabled0改为enabled1然后sudo dnf clean all sudo dnf makecache这是最常见的原因。有时系统更新或安全加固脚本会自动禁用非核心仓库。仓库 baseurl 错误sudo vi /etc/yum.repos.d/centos-appstream.repo检查baseurl行确保它指向http://mirror.centos.org/$contentdir/$releasever/AppStream/$basearch/os/这样的有效路径如果你手动修改过 repo 文件可能写错了$符号或路径。DNS 或网络问题ping -c 3 mirror.centos.org和curl -I http://mirror.centos.org如果 ping 不通或 curl 返回 404说明是网络层问题需要联系网络管理员。4.3 “error installing 24.16.0: node.js v24.16.0 is not yet released” —— 版本号幻觉这个错误非常直白Node.js 官网根本没有发布v24.16.0这个版本。nvm的ls-remote命令有时会因为缓存或网络问题显示一个错误的、未来版本的列表。解决方案操作步骤说明刷新 nvm 缓存nvm cache clear nvm ls-remote这是最快的方法清除本地缓存后重新获取远程列表。手动访问官网确认在浏览器中打开https://nodejs.org/dist/这是唯一权威的来源。你会看到所有已发布的版本按时间倒序排列。安装一个已知存在的版本nvm install 22.14.022.x是当前最新的 LTS 版本22.14.0是截至 2024 年 10 月的最新 patch 版本非常稳定。4.4 “node -v 正常但 npm -v 报 command not found” —— PATH 的迷宫node和npm是两个独立的可执行文件它们被一起打包在 Node.js 的 tarball 里但nvm在安装时会把它们都放到~/.nvm/versions/node/vX.X.X/bin/目录下。如果PATH里只有node的路径而没有npm的路径就会出现这个现象。排查步骤操作命令说明1. 查看当前 PATHecho $PATH确认输出中是否包含~/.nvm/versions/node/v18.20.2/bin。2. 查看该目录下是否有 npmls -l ~/.nvm/versions/node/v18.20.2/bin/npm如果文件存在说明npm已安装问题纯属 PATH。3. 临时修复export PATH$HOME/.nvm/versions/node/v18.20.2/bin:$PATH这条命令会立即将npm的路径加入PATH用于快速验证。4. 永久修复将上面的export命令添加到~/.bashrc的末尾然后source ~/.bashrc这是根治方法。提示nvm的use命令会自动更新PATH所以如果你执行了nvm use 18.20.2npm就应该立刻可用。如果不行说明nvm use本身就没成功回到问题 4.1 去排查。5. 后续维护与升级策略让 Node.js 环境持续健康运转安装完成只是起点Node.js 环境的长期健康取决于一套清晰的维护策略。在 CentOS 8 这个已进入 EOL2021年12月31日的系统上这一点尤为重要。5.1 版本升级LTS 还是 Current一个关乎稳定与创新的抉择Node.js 的版本发布遵循一个明确的周期每年 4 月发布一个Current版本如 22.x该版本拥有最新特性但只维护 6 个月每年 10 月一个Current版本会晋升为LTS长期支持版本如 20.x获得 30 个月的维护期期间只接收安全补丁和关键 bug 修复。对于生产环境我的铁律是永远使用 LTS 版本。Current版本的快速迭代虽然带来了fetchAPI、Web Crypto等激动人心的新特性但也伴随着频繁的 API 变更和未被充分测试的边缘 case。我曾在一个内部工具项目中尝鲜Node.js 21.x结果因为一个底层 V8 引擎的 GC垃圾回收算法变更导致应用在高负载下内存占用飙升 300%排查了整整一周才定位到根源。而 LTS 版本经过了全球数百万开发者的生产环境检验其稳定性是Current版本无法比拟的。因此我的升级策略是每半年即每年 4 月和 10 月检查一次nvm ls-remote --lts的输出当一个新的 LTS 版本如22.x发布后我会在测试环境先用nvm install --lts安装它然后运行完整的自动化测试套件包括单元测试、集成测试和性能基准测试。只有当所有测试 100% 通过且没有观察到任何异常的内存或 CPU 波动后才会在灰度环境上线最后推广到全量生产环境。这个过程通常需要 2-4 周但它换来的是线上服务的绝对稳定。5.2 安全监控主动防御而非被动救火Node.js 的安全漏洞往往藏在你依赖的第三方包里而不是 Node.js 本身。npm audit是一个强大的内置工具它会扫描你的package-lock.json并与 npm 官方的漏洞数据库进行比对。# 在你的项目根目录下运行 npm audit # 输出会列出所有已知的高危high、严重critical漏洞并给出修复建议。 # 例如 # npm audit security report # # Run npm update minimist --depth 4 to resolve 1 vulnerability # Critical Command Injection # Package minimist # Dependency of myapp [dev] # Path myapp webpack yargs minimist # More info https://npmjs.com/advisories/1179npm audit fix可以自动修复大部分低危和中危漏洞但对于高危和严重漏洞它通常会提示manual review required。这时你需要手动执行它建议的npm update命令或者更稳妥的做法是直接在package.json中将相关依赖的版本号升级到一个已修复的版本然后运行npm install。我习惯将npm audit集成到 CI/CD 流水线中作为build阶段的一个必过检查项。如果npm audit --audit-levelmoderate将中危及以上视为失败返回非零状态码整个构建就失败阻止有安全风险的代码进入测试环境。这是一种“左移”的安全实践成本最低效果最好。5.3 环境迁移当 CentOS 8 终将成为历史你的 Node.js 如何优雅谢幕CentOS 8 已于 2021 年底结束生命周期这意味着它不再接收任何安全更新。继续在生产环境使用它本身就是一种巨大的安全风险。因此规划一个平滑的迁移路径是每个运维工程师的必修课。我的建议是不要试图在 CentOS 8 上“打补丁”来延长它的生命而是将 Node.js 作为迁移的先锋队。具体操作是在新的目标系统如 Rocky Linux 9 或 AlmaLinux 9上用完全相同的nvm流程安装相同版本的 Node.js如 18.20.2然后将你的应用代码、package