nvm use 切换后 node -v 仍显示旧版本，根本原因是 nvm 未持久注入 shell 环境；需确保 ~/.zshrc（或 ~/.bashrc）中正确加载 nvm.sh 并执行 source 重载，而非仅重启终端。
为什么 nvm use 切换后 node -v 还是旧版本？
常见现象：执行 nvm use 18.19.0 显示 “Now using node v18.19.0”，但新开终端或运行 node -v 仍输出旧版本（比如 v16.20.2）。根本原因不是命令失效，而是 nvm 的 shell 环境未持久注入。
实操要点：
-
nvm本身不修改系统级PATH，它只在当前 shell session 中通过 alias 和 PATH 前置临时生效 - 必须确保 shell 启动文件（如
~/.bashrc、~/.zshrc）中已加载nvm脚本，典型写法是：export NVM_DIR="$HOME/.nvm"<br>[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
- Zsh 用户还需额外加载 completion：
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"
- 改完配置后必须重载：
source ~/.zshrc（或source ~/.bashrc），不能只靠关掉再开终端——某些终端（如 VS Code 集成终端）会复用旧 shell 环境
nvm install 和 nvm install --lts 有什么实际区别？
区别不在安装逻辑，而在版本解析和后续默认行为。直接指定版本号（如 nvm install 20.13.1）精准可控；而 --lts 是符号引用，背后绑定的是当前 LTS 命名（如 hydrogen），不是固定数字版本。
关键影响：
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
-
nvm install --lts每次运行可能装不同版本（取决于 npm registry 中lts/*的最新映射），例如今天装的是 v20.13.1，下周可能变成 v20.14.0 -
nvm alias default lts/*会让nvm use无参数时自动选最新 LTS，但项目里用.nvmrc时仍建议写死数字版本（如20.13.1），避免 CI/CD 或队友环境漂移 - 查当前所有 LTS 别名：运行
nvm ls-remote --lts，输出里带(Latest LTS: ...)的那行才是当前默认指向
如何让项目自动匹配 .nvmrc 中的 Node 版本？
自动切换 ≠ 默认开启。即使项目根目录有 .nvmrc（内容为 18.19.0），nvm 也不会主动触发 use —— 它只是个静态声明文件。
要实现“进目录自动切版本”，需手动加壳或依赖工具链：
- 最轻量：在
~/.zshrc（或对应 shell 配置）里追加函数cd() {<br> builtin cd "$@"<br> [[ -f .nvmrc ]] && nvm use 2>/dev/null<br>}注意：该方式对子 shell（如脚本内cd）无效，且可能干扰某些 IDE 终端 - 更可靠：用
direnv+nvm，在项目根建.envrc：use nvm
然后运行direnv allow；direnv会在进入目录时真正执行环境切换，包括PATH、NODE_OPTIONS等完整继承 - 验证是否生效：执行
nvm current，应输出与.nvmrc一致；若输出none，说明自动触发失败，优先检查direnv是否启用或 shell 函数是否被覆盖
Windows 上能用 nvm-windows 实现同样效果吗？
不能完全等价。虽然 nvm-windows 提供了类似命令（nvm use 18.19.0），但它底层是复制 Node 安装目录并修改 Windows PATH 环境变量，每次切换都会触发注册表/环境变量写入，速度慢、权限要求高，且与 WSL 中的 nvm 行为不兼容。
真实限制：
-
nvm-windows不支持.nvmrc自动识别，也无direnv生态配合方案 - PowerShell 下常遇到执行策略报错：
File ...nvm.ps1 cannot be loaded because running scripts is disabled，需手动运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser - 多 Node 并存时，
nvm-windows的node_modules全局缓存路径（%APPDATA%\nvm）与各版本强绑定，但npm config get prefix可能意外指向旧版本路径，导致全局包安装错位 - 跨平台协作项目强烈建议：Windows 用户直接使用 WSL2 + 原生
nvm，而非nvm-windows；WSL2 中的体验与 macOS/Linux 几乎一致，且规避了 Windows 权限与路径语义差异
nvm 与 corepack、pnpm 或自定义 npm config 共存时，一个没对齐的 PATH 前缀就足以让 which node 和 process.version 对不上号。 
