升级 Node.js 前，如何盘点开发机、CI 和生产环境的版本与安装来源

升级前，分别在日常开发终端、运行构建或测试的 CI 作业，以及生产应用的运行环境中检查。开发机的结果不能代替 CI；Dockerfile 中的基础镜像也不能代替运行容器中的实测。每处记录版本、路径和安装来源线索，无法确认的项目标为待查。

先确定每个环境要记录什么

在需要核对的同一执行上下文中，由你自行运行以下命令。每条命令分别记录结果；其中路径命令是依据 Node.js 的打印选项和 process.execPath 属性组合的实践示例，并非上游文档中的完整逐字命令。

node -v
npm -v
node -p "process.execPath"

建议每个环境或服务单独记一行：检查时间、环境或服务名、执行位置和用户、相关 shell 或 CI 作业及步骤、三条命令的输出、来源线索和待确认项。容器还应记录目标容器和实际部署的镜像信息；CI 有多个作业或矩阵组合时，分别记录实际执行的组合。

如果某条命令找不到或执行失败，保留原始错误、执行位置和上下文，把对应结果标为未知，不要用其他环境的结果补全。命令未找到只表示当前上下文没有成功调用它，并不能证明软件从未安装。

开发机：定位 PATH 和 nvm 差异

1. 在日常运行项目命令的终端中执行三条检查。项目若由不同用户或 shell 运行，分别检查并记录。
2. 在相应的 POSIX shell 中检查命令名如何被当前 shell 解析，再将结果与版本和可执行文件路径对照。
3. 如果当前 shell 已加载 nvm，检查其当前活动 Node.js 路径，并与项目版本配置比较。
4. 版本或路径仍不符合预期时，核对用户、shell、PATH、项目配置和安装记录；解释不了的差异保留为待查。

第二步可使用下面的组合排查示例，适用于相应的 POSIX shell，不是 Windows 原生命令提示符的通用方案：

command -v node
command -v npm

输出说明 shell 如何解释命令名，不一定都是文件路径：别名可能显示定义，函数可能只显示名称；通过 PATH 找到的可执行工具则可显示路径。没有输出表示当前 shell 未找到该名称。若显示的是路径，比较它与 process.execPath 的结果；后者解析符号链接，因此路径文字不同本身并不能证明调用了不同安装。若显示别名或函数，应继续查看该 shell 的相关定义和配置。

在当前 shell 已加载 nvm 时，第三步可运行：

nvm which current

nvm 文档中的 current 指当前 shell 通过 PATH 解析到的活动 Node.js 版本，不受 .nvmrc 影响；这条命令打印当前活动 node 的路径。nvm 切换版本时会修改 PATH。.nvmrc 是项目期望版本的线索，不是当前版本的实测结果，也不要假定进入目录就一定会自动切换。比较 nvm 路径与 process.execPath 时，同样要考虑符号链接。

nvm 按用户安装、按 shell 调用，一个终端的结果不能自动代表另一个。若在 Linux 上运行 nvm 安装脚本后出现 nvm: command not found，或 command -v nvm 没有输出，nvm 文档建议关闭当前终端、打开新终端后重新验证；也可按其文档针对相应 shell 加载配置。这是安装后的限定排查，不是所有 Node.js 问题的通用修复。

GitHub Actions：在实际作业中复核

1. 找到实际运行构建或测试的作业及其版本设置。若有矩阵，检查每个相关组合。
2. 在版本设置之后、项目命令运行的上下文中执行三条检查并保存日志。确认日志所属作业和步骤，再与配置比较。
3. 若版本或路径不符，检查此前的版本设置、安装方式以及项目命令自身的执行环境；缺少证据时保留日志并标为待查。

下面是仅适用于 GitHub Actions 的组合示例，可作为作业 steps 的一部分。版本 24 只是配置示例，应按项目需要调整；示例没有在读者的 CI 中运行。

steps:
  - uses: actions/setup-node@v7
    with:
      node-version: 24
  - name: Check Node.js version
    continue-on-error: true
    run: node -v
  - name: Check npm version
    continue-on-error: true
    run: npm -v
  - name: Check Node.js executable
    continue-on-error: true
    run: node -p "process.execPath"

检查被拆成独立步骤，并临时允许检查步骤失败，以便一条命令失败时仍能看到其余结果。请逐项查看日志中的错误，不要把作业继续执行当作检查成功；盘点完成后按团队的 CI 策略移除或调整这些临时设置。如果项目命令使用不同的容器、用户或其他执行配置，应在其实际上下文中复核，而不能仅依赖相邻步骤的结果。

对于所读文档中的 actions/setup-node@v7，node-version 未提供时文档说明会使用 PATH 中的版本；同时提供 node-version 和 node-version-file 时，node-version 优先。检查两项配置及相应版本文件，最终仍以相关运行步骤的输出确认实际版本。这些规则不应直接套用到其他 CI 配置。

生产环境：在已进入的运行容器中检查

1. 先确认服务的部署方式、目标实例和检查权限。应用运行在容器中时，进入目标运行容器，而不是只检查管理机或构建机。
2. 在已进入的容器中运行前述三条命令，记录服务、实例、容器、执行身份、输出及实际部署的镜像信息。多个相关实例或容器分别核对。
3. 对照部署记录、Dockerfile 和启动配置。若结果与预期不符，继续核对应用的启动方式、执行身份和所用可执行文件。

若容器中找不到 npm，记录不可用及原始错误，不要据此推断 Node.js 也不存在。容器内有适用的 POSIX shell 时，可使用前述 command -v 检查当前 shell 的解析情况；仍无法确认则标为待查。

这些命令启动的是新进程，不一定等同于已经运行的应用进程。无法验证已有进程时，应明确标记这一限制。镜像信息和 Dockerfile 有助于追查来源，但基础镜像配置不能单独证明运行容器实际使用的版本。

完成盘点：解释差异，不猜测来源

逐项比较 Node.js 版本、npm 版本和路径。版本不同，先确认用户、shell、PATH、CI 版本设置和目标容器；版本相同但路径不同，则结合符号链接、安装记录和启动配置继续核对。失败的检查不要与成功输出作版本比较。

可执行文件路径、npm 版本和 nvm 当前路径都是线索，不能单独证明安装包从哪里下载或由谁安装。盘点完成时，每个相关环境都应有可定位的执行位置和结果；每项差异要么有证据解释，要么列为待查。

本文资料核对日期为 2026-11-07。所用主分支文档可能变化，具体行为应以实际安装的 Node.js、npm、nvm 版本及运行环境为准。

raw.githubusercontent.com

raw.githubusercontent.com

raw.githubusercontent.com

command

raw.githubusercontent.com

raw.githubusercontent.com