NVM管理Node版本：新手老手都能避免翻车，你了解吗？

xmlns="http://www.w3.org/2000/svg"

style="display:

none;">

前端必备：NVM管理Node版本不翻车，新手老手都能用

前端必备：NVM管理Node版本不翻车，新手老手都能用
- 先说个扎心的事儿
- NVM到底是个什么鬼
- 为啥非得用这玩意儿不可
- 安装过程其实没那么复杂
- - Mac用户看这里
  - Windows用户看这里
  - Linux用户看这里
  - 常见安装坑
- 常用命令给你捋一遍
- - 查看和安装版本
  - 切换和使用版本
  - 设置别名和默认版本
  - 卸载和维护
  - Windows版的一些差异
- 实际项目里怎么玩转
- - 项目根下建个.nvm文件夹，里面给每个Node版本都搞个独立的小房间。
    当你nvm
    use
    18的房间门打开，把路径指向那里；当你nvm
    use
    14的时候，又切换到另一个房间。
    各个版本之间井水不犯河水，全局安装的包也是分开存放的，互不干扰。
    这里有个细节可能有人没注意：NVM管理的Node版本，和你去nodejs.org官网下载的.pkg或.msi安装包安装的Node，在系统里是两码事。
    如果你之前手动装过Node，最好先把那个卸载干净，再让NVM接管，不然容易打架。
    为啥非得用这玩意儿不可
    你想想啊，现在前端生态更新这么快，Node几乎年年大版本迭代，LTS长期支持版本都赶趟儿似的。
    2023年Node
    22又来了，这谁顶得住？
    老项目依赖旧版本，可能是因为某个古老的依赖包还没适配新API；新项目要用新特性，比如Node
    Runner；测试还得覆盖多个版本，确保你的库在Node
    14到Node
    20都能跑。
    没有NVM的话，你每次切换都得手动卸载安装，npm全局包全得重装，耗时耗力还容易出错。
    更现实的问题是团队协作。
    你电脑上是Node
    14，同样的代码在不同机器上表现可能完全不一样。
    最常见的就是package-lock.json冲突，Node版本不同生成的lock文件结构都有差异，合并代码时简直噩梦。
    有了NVM，一条命令秒切版本，效率直接拉满。
    而且配合.nvmrc文件，可以做到项目级别的版本锁定，从根本上解决"在我电脑上能跑"的经典难题。
    安装过程其实没那么复杂
    Mac用户看这里
    Mac用户最爽，直接用Homebrew一条龙服务：
```
#先确保你有Homebrew，没有的话去brew.sh装一个brewinstallnvm
```
    装完之后，别急着用，还得告诉shell怎么加载它。
    打开你的shell配置文件，如果是zsh（Mac
    Catalina之后默认就是这个）就编辑~/.zshrc，如果是bash就编辑~/.bash_profile或~/.bashrc：
```
#
在文件末尾加上这两行exportNVM_DIR="$HOME/.nvm"[-s"/opt/homebrew/opt/nvm/nvm.sh"]&&\."/opt/homebrew/opt/nvm/nvm.sh"#
This
nvm[-s"/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm"]&&\."/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm"#
Thisbash_completion
```
    注意啊，M1/M2/M3芯片的Mac，Homebrew路径可能在/opt/homebrew，Intel芯片的在/usr/local/opt/nvm，上面那段配置要对应修改。
    我之前就栽过这个坑，复制粘贴网上的配置发现不生效，后来才发现路径不对。
    加完配置后，记得source一下或者重启终端：
```
source~/.zshrc#
验证安装nvm的版本号
```
    Windows用户看这里
    Windows用户去GitHub搜nvm-windows，找coreybutler维护的那个项目，下载最新的nvm-setup.exe安装包。
    安装过程一路下一步就行，但有个地方要注意：安装路径最好别带空格和中文，比如别装在C:\Program
    Files\nvm，容易出各种玄学问题。
    我习惯装在C:\nvm或者D:\nvm。
    装完之后，新开一个PowerShell或者CMD窗口（注意一定要新开，旧的缓存了环境变量），输入：
```
nvm
version#1.1.12
```
    Windows版有个小差异，它用nvm
    list
    available查看可安装版本，而Mac/Linux版是nvm
    ls-remote。
    这个后面会细说。
    Linux用户看这里
    Linux用户通常用curl或wget下载安装脚本执行：
```
#
用curlcurl-o-
https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh|bash#
或者用wgetwget-qO-https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh|bash
```
    脚本会自动往你的~/.bashrc、~/.zshrc或~/.profile里追加配置。
    装完同样要source一下或者重新登录。
```
source~/.bashrc
nvm--version
```
    常见安装坑
    这里有个
    universal
    的坑，不管你什么系统都可能遇到：装完记得完全重启终端，甚至重启电脑。
    有时候环境变量已经写进去了，但当前终端会话没加载，你输入nvm就提示command
    not
    found，其实并不是没装好，只是需要刷新一下。
    还有一个权限问题，特别是在公司电脑或者有IT管控的机器上。
    Mac/Linux如果遇到Permission
    denied，检查下.nvm，而不是系统放.nvmrc
    这是最重要的一个习惯。
    每个项目根创建.nvmrcecho"18.19.0">.nvmrc#
    或者写大版本号，自动用最新的18.xecho"18">.nvmrc#
    也可以用别名echo"lts/*">.nvmrc
    同事拉下代码后，只需要在项目下的.nvmrc文件并切换到对应版本。
    如果本地没装这个版本，会提示你先nvm
    install。
    配合package.json的engines字段
    .nvmrc是给NVM看的，package.json里的engines字段是给npm看的，双保险：
```
{"name":"my-awesome-project","version":"1.0.0","engines":{"node":">=18.0.0<19.0.0","npm":">=10.0.0"}}
```
    这样如果用户用了错误的Node版本运行npm
    install，npm会发出警告。
    配合一些CI工具，还可以强制检查。
    加个npm脚本检测版本
    有时候.nvmrc容易被忽略，可以在package.json里加个前置脚本：
```
{"scripts":{"preinstall":"node
\"const
}\"","start":"react-scripts
start","build":"react-scriptsbuild"}}
```
    这样每次npm
    install前都会检查Node版本，不对就报错退出，从源头避免版本问题。
    CI/CD流水线配置
    GitHub
    Actions、GitLab
    Actions为例：
```
#
.github/workflows/ci.ymlname:CIon:[push,pull_request]jobs:build:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4#
安装NVM并读取.nvmrc-name:Setup
Node.jsuses:actions/setup-node@v4with:node-version-file:'.nvmrc'#
自动读取.nvmrccache:'npm'-run:npm
ci-run:npm
run
build-run:npmtest
```
    这样保证构建环境和开发环境完全一致，再也不怕"我本地能构建，CI却挂了"的尴尬。
    团队多人协作规范
    我们团队内部有个不成文的规定：
    1. 每个项目必须有.nvmrc文件，代码审查时检查
    2. 新人入职文档里专门有一节"安装NVM并运行项目"
    3. 项目README里第一段就是环境要求，加粗提示
    4. 定期（比如每季度）评估升级Node版本，统一迁移
    这些习惯能省掉一堆沟通成本。
    以前经常有同事在群里问"我这个报错是为什么"，后来发现八成是Node版本不对。
    现在有了.nvmrc，这类问题基本绝迹。
    这玩意儿有啥优缺点
    优点很明显
    切换快：一条命令秒切，比手动卸载重装快多了。
    特别是需要同时维护多个项目时，效率提升巨大。
    隔离好：每个版本的Node和全局包都是独立的。
    你在Node
    18全局装了pnpm，切换到Node
    16时看不到它，互不干扰。
    这避免了版本间的污染问题。
    不污染系统环境：NVM把一切都放在用户存在不
  - 检查shell配置文件里有没有加载NVM的脚本（前面安装部分的那两行）
  - 检查路径对不对，特别是M1
    Mac的Homebrew路径
  - 执行source
    ~/.zshrc（或对应的配置文件）刷新当前终端
  - 如果都不行，试试重启终端或重启电脑

标签： 新手老手都能用前端必备：NVM管理Node版本不翻车

服务项目	基础套餐	标准套餐	高级定制
关键词优化数量	10-20个核心词	30-50个核心词+长尾词	80-150个全方位覆盖
内容优化	基础页面优化	全站内容优化+每月5篇原创	个性化内容策略+每月15篇原创
技术SEO	基本技术检查	全面技术优化+移动适配	深度技术重构+性能优化
外链建设	每月5-10条	每月20-30条高质量外链	每月50+条多渠道外链
数据报告	月度基础报告	双周详细报告+分析	每周深度报告+策略调整
效果保障	3-6个月见效	2-4个月见效	1-3个月快速见效

百度SEO

NVM管理Node版本：新手老手都能避免翻车，你了解吗？

style="display:

前端必备：NVM管理Node版本不翻车，新手老手都能用

use

use

为啥非得用这玩意儿不可

14到Node

安装过程其实没那么复杂

Mac用户看这里

This

This

验证安装nvm

Windows用户看这里

version#

list

Linux用户看这里

nvm

常见安装坑

universal

not

配合package.json的engines字段

加个npm脚本检测版本

\"const

CI/CD流水线配置

Actions、GitLab

run

团队多人协作规范

这玩意儿有啥优缺点

优点很明显

切换了版本但node-v没变

use

全局包不见了

和同类工具比咋样

nvm-fish

fnm

(Fast

Volta

怎么选？

一些掏心窝子的建议

别在项目里写死绝对路径

团队内部统一工具链

定期更新NVM本身

upgrade

重要项目锁定版本，别盲目追新

备份你的.nvmrc和配置

最后

为您推荐

SEO优化服务内容导航

SEO优化服务概述

SEO优化核心服务

网站技术SEO

内容优化服务

外链建设策略

SEO服务方案对比

SEO优化实施流程

网站诊断分析

关键词策略制定

技术优化实施

内容优化建设

外链建设推广

数据监控调整

SEO优化常见问题

SEO优化效果数据

行业案例 - 制造业

行业案例 - 电商

行业案例 - 教育

为什么选择我们的SEO服务

专业团队

数据驱动

透明合作

我们的SEO服务理念

提交需求或反馈

产品中心

SEO基础

SEO技术

联系我们

QQ在线客服

关注微信

`use`

`use`

`为啥非得用这玩意儿不可`

`14到Node`

`安装过程其实没那么复杂`

`Mac用户看这里`

`Windows用户看这里`

`list`

`Linux用户看这里`

`常见安装坑`

`universal`

`not`

切换了版本但node
-v没变

`use`