nvm：Node 版本与 shell 状态
nvm 内部架构：已安装版本、shell 状态与子进程执行
追踪 Node 存储目录、选择器、PATH 变更与明确 exec 命令创建的进程，理解各层职责。
你将学会
- 存储与选择属于不同层
- use 分支更新调用它的 shell
- 明确的子命令有独立生命周期
开始前需要
- 了解 shell 命令和进程环境
- 区分运行时安装与版本选择
诊断项目请求与实际 Node 版本的差异，并制定明确的接入和验证边界。
先看结论
- 已存储版本、选择器和运行进程是不同状态。
- shell 函数能更新启动后续进程的环境。
- 辅助函数正确不等于整个安装执行生命周期已验证。
存储与选择属于不同层
nvm 在选定目录下维护版本目录，以及别名、缓存等辅助状态。完整版本、default、current 等选择器，需要先解释，命令才能决定执行什么。.nvmrc 解析器只返回文本，将文本解析为已知且已安装运行时则是后续职责，两者不能合并为一个成功判断。
这种分层解释了为什么请求解析成功后，版本选择仍可能失败；也解释了修改默认别名与立即改变所有活动 shell 为什么不同。应分别检查已存储版本、所用选择器和活动进程，而不是把它们当成一个机器全局版本变量，否则排障容易检查错层。
use 分支更新调用它的 shell
检查所选版本后，use 分支计算版本目录并调用 nvm_change_path，然后导出 PATH，更新相关手册路径，重置 shell 命令缓存，并设置 NVM_BIN、NVM_INC。这就是 nvm 作为 shell 函数加载的原因：普通独立可执行文件不能直接重写父 shell 的环境。
可选 NVM_SYMLINK_CURRENT 路径还有额外文件系统副作用，会替换 current 链接。理解普通按 shell 选择并不需要启用它，教程也不应偷偷打开。本次辅助函数实验只传入字面 PATH 字符串，没有进入会导出环境变量和可能更新状态的完整 use 分支。
明确的子命令有独立生命周期
小型 nvm-exec 脚本在关闭自动选择的情况下加载管理器，选择版本后用 exec 替换自身来执行请求的命令。相比依赖当前状态的省略选择器，明确版本更容易推理。进程启动依然不同于安装发行包或修改启动配置，不能用其中一项成功证明其余全部成功。
实验覆盖提取的文本处理辅助函数，不覆盖所有调用方、shell 或进程生命周期。它展示了可独立测试的接口：PATH 变换和 .nvmrc 内容解析，可以与下载、目录结构和应用执行分离观察。宣布真实接入成功前，仍要通过集成测试把这些部分连接起来。
实施步骤
- 1
确定选择器来源。
- 2
追踪解析到已安装版本目录。
- 3
检查 use 分支的环境变更。
- 4
单独验证在该环境下启动的命令。
可复制示例
选择器 / .nvmrc -> 版本解析 -> 已安装目录
|
调用 shell <- PATH + NVM_BIN + NVM_INC <- use
|
+-> 新启动的 Node 进程
已有进程：保持不变常见问题
为什么通常加载 nvm，而不是把它当程序执行？
它定义能改变调用 shell 环境的函数，普通子程序不能直接改变父进程 PATH。
辅助函数实验执行了 nvm use 吗？
没有。只用字面输入执行选定函数，未运行导出环境变量、可能更新状态的完整命令分支。