nvm：Node 版本与 shell 状态
团队与 CI 部署 nvm：shell 初始化也是构建的一部分
规划管理器固定版本、启动配置责任和非交互初始化，避免把交互终端当成可复现 CI 环境。
你将学会
- 先定义安装允许改变什么
- 非交互任务需要明确初始化
- 生产进程启动又是一个边界
开始前需要
- 了解 shell 命令和进程环境
- 区分运行时安装与版本选择
诊断项目请求与实际 Node 版本的差异，并制定明确的接入和验证边界。
先看结论
- 禁止启动配置编辑，不等于禁止安装写入。
- 每个非交互 shell 都需要明确初始化路径。
- 服务启动应使用真实服务身份验证运行时。
先定义安装允许改变什么
检查的 install.sh 会选择目标目录、获取管理器文件，并检测应追加加载语句的启动配置。PROFILE=/dev/null 可关闭配置文件编辑步骤，但不会把安装变成只读操作。团队接入记录应包含管理器修订、安装目录、目标配置文件，以及是否还会安装请求的 Node 版本。
执行下载的安装器前先审查内容，并在接入记录保留来源身份。混用手工与安装器维护的加载行前，应检查重复项。配置文件选错或 shell 没初始化，可以解释许多命令找不到的问题；反复下载同一个安装器，不能替代确认该 shell 到底读取哪个文件。
非交互任务需要明确初始化
CI 步骤的 shell 类型不一定与开发者终端相同。README 讨论了明确加载，以及用 Bash BASH_ENV 配置非交互环境的方式。选择一种有意识的机制并在真实 runner 测试；只有 NVM_DIR 变量，不会自动定义 nvm 函数，也不会自动选择 Node 可执行文件。
分别固定管理器和运行时版本，在任务日志显示实际运行时，但不要打印秘密。若每个 CI 步骤启动新的 shell，上一步的选择不会自动成为下一步的 shell 状态。在执行构建前先初始化并选择版本的包装脚本，可以把这个进程边界明确表达出来。
生产进程启动又是一个边界
nvm-exec 使用 --no-use 加载管理器，经 NODE_VERSION 或项目查找路径选择版本，再通过 exec 执行目标命令。这解释了预期子进程边界，但本次只阅读了该脚本，没有实际运行。生产服务账号、权限、可执行路径与重启行为，仍需按环境验证。
把运行时升级当作需要应用验收和回退计划的变更。版本目录仍在磁盘，不代表服务能够使用它，也不代表依赖兼容。本文给出接入检查清单，不声称已经成功构建、部署某个容器镜像、CI 任务或生产服务；这些验收必须有各自实际证据。
实施步骤
- 1
记录管理器与运行时固定版本、目录和配置负责人。
- 2
审查安装器并批准预期写入。
- 3
在新的非交互 runner shell 测试初始化。
- 4
修改服务前验证应用并记录回退方式。
可复制示例
# CI 包装片段：nvm 和该运行时必须已经安装
# NVM_DIR 由经过批准的 runner 配置提供
. "$NVM_DIR/nvm.sh" --no-use || exit 1
nvm use 24.14.0 || exit 1
nvm which current
node --version
# 只有这些检查通过后才运行项目构建常见问题
PROFILE=/dev/null 表示不安装任何东西吗？
不是。它关闭启动配置编辑，管理器下载和其他安装行为仍是独立动作。
为什么下个 CI 步骤没有 nvm？
该步骤可能启动了未经初始化的新 shell。应检查 runner 的实际进程边界，而不是依赖此前交互终端。
资料来源
- README.md来源核查 2026-09-08
- install.sh来源核查 2026-09-08
- nvm-exec来源核查 2026-09-08