1、安装npm需要安装nodejs，node中自带npm包管理器
node下载地址：node.js
2、cnpm安装（需要安装npm）
cnpm是淘宝团队做的npm镜像，淘宝镜像每 10分钟 进行一次同步以保证尽量与官方服务同步。
npm install -g cnpm --registry=https://registry.npm.taobao.org
3、yarn安装（需要安装npm）
npm install -g yarn
官网地址：安装 | Yarn 中文文档
4、pnpm安装（需要安装npm）
npm install -g pnpm
官网地址： pnpm 中文文档
1、并行安装：yarn安装包会同时执行多个任务，npm 需等待上一个任务安装完成才能运行下一个任务（按照在package.json中声明的顺序）,所以npm install 下载速度慢，即使是重新 install 时速度依旧慢
2、离线模式：如果你已经安装过一个包，用 yarn 再次安装会从缓存中获取，而 npm 会从网络下载
3、版本锁定：yarn 默认有一个 yarn.lock 文件锁定版本，保证环境统一，npm是通过
package-lock.json
4、更简洁的输出：yarn 安装包时输出的信息较少，npm 输出信息冗余
5、常用指令对比：
当我们运行npm i lodash --save，lodash将会被当做依赖加入到package.json中：
"dependencies": {
"loadsh": "^4.17.4"
}
由于package.json文件中的版本号的特点，下面的三个版本号在安装的时候就代表不同的含义。
"6.0.3"表示安装指定6.0.3版本，
"~6.0.3"表示安装6.0.X中最新的版本，
"^6.0.3"表示安装6.X.X中最新的版本，
举个例子：以typescript依赖包为例
1、原项目中使用package.json定义项目中需要依赖的包，这里的typescript版本号为^4.2.4
2、原项目是用npm来进行包管理，从而生成package-lock.json文件，里面存储了各个依赖的具体来源和版本号，其中typescript的版本号为4.2.4，所以今后使用npm进行安装依赖时都会安装typescript的4.2.4版本，不会进行自动升级
3、如开发者使用yarn命令来进行包依赖安装，则package-lock.json文件无效，只看package.json中的文件，但typescript版本号为^4.2.4，从而会安装4.x.x版本中最新版本即为4.6.3版本，同时生成对应yarn.lock文件
4、启动项目会出现typescript类型报错，其原因是因为原项目是在4.2.4typescript版本环境下编写，但使用yarn进行依赖安装把typescript版本自动更新成了 4.6.3版本，同时4.2.4和4.6.3版本的typescript在类型校验上进行了较大的改进和优化，可以检测出更多的类型问题
所以，如有yarn.lock文件而没有package-lock.json文件则项目是以yarn 来进行包管理；
如有package-lock.json文件而没有yarn.lock文件则项目是以npm来进行包管理。
关于版本也可以参考这篇文章 https://blog.csdn.net/big_wolf0/article/details/124294655
1、在npm3以前，采用的是嵌套安装的方式。假如我们安装依赖B和C时，如果B和C依赖中依赖了 packageD，那么会将 packageD重复安装2次。这将导致 会占据比较大的磁盘空间，且 windows 的文件路径最长是 260 多个字符，这样嵌套是会超过 windows 路径的长度限制的。
2、npm3+和yarn采取铺平的方式，将依赖扁平化，所有的依赖不再一层层嵌套了，而是全部在同一层，这样也就没有依赖重复多次的问题了，也就没有路径过长的问题了。
npm2生成的依赖管理比较的简单直接，会按照安装包的依赖树形结构直接填充在本地的目录结构下：
比如express和koa他们会同时依赖accepts，那么在install之后生成的node_modules就会是如下结构
npm2的这种方式的优点就是比较的直观，但是呢缺点也是显而易见的就是
层级依赖过深
相同包的相同版本会多次被下载，利用率低，占用磁盘空间大
针对npm2的两个缺点呢，npm3做了个改变，不再使用嵌套的结构了，而是讲依赖进行打平，这样就能解决层级依赖深和包的利用率的问题，那么上面的依赖关系就会变成下面这个样子：
我们可以看出，express@4.18.1和koa@2.13.4引用了accepts的版本是一样的，这样才会被平铺在node_modules下，那如果引用的包的版本不一样又是什么样的情况呢？就像debug,http-errors 、statuses等这几个包
express@4.18.1引入的是:debug@2.6.9、http-errors@2.0.0、statuses@2.0.1
koa@2.13.4引入的是:debug@4.3.2、http-errors@1.6.3、statuses@1.5.0
此时，在node_modules结构是下面这个样子
npm3的这种平铺方式确实是解决了层级依赖深和包的利用率的问题，但是也引入了其他的问题：
创建非扁平化的node_module文件夹
在pnpm创建非扁平化的结构过程中，这里出现了两种箭头指示：
Hard Link
Symbolic Link
什么是Hard Link？
字面意思：硬链接
hard link 使得用户可以通过不同的路径引用方式去找到某个文件
可以看官方文档中的图片，链接指向的都是.pnpm store
pnpm在这里存放了所有依赖的Hard Links，每个依赖可以理解为只存在一份，且在store中。
什么是Symbolic Link？
字面意思：符号链接
可以看作为我们常规操作的快捷方式，当其他依赖需要相同依赖的时候，采用符号链接而不需重新下载。详细的看访问官网查看https://pnpm.io/zh/motivation
官方给的一些对比
详细访问改地址https://pnpm.io/zh/feature-comparison
项目初衷
使用 npm 时，依赖每次被不同的项目使用，都会重复安装一次。 而在使用 pnpm 时，依赖会被存储在内容可寻址的存储中，所以：
pnpm 分三个阶段执行安装：
使用 npm 或 Yarn Classic 安装依赖项时，所有的包都被提升到模块目录的根目录。 这样就导致了一个问题，源码可以直接访问和修改依赖，而不是作为只读的项目依赖。
默认情况下，pnpm 使用符号链接将项目的直接依赖项添加到模块目录的根目录中。
更详细的可以查看官网https://pnpm.io/zh/cli/env
从源中获取包而不将其安装为依赖项，热加载，并运行它公开的任何默认命令二进制文件。
管理 Node.js 环境。
使用
安装并使用指定版本的 Node.js
安装 LTS 版本的 Node.js：
pnpm env use --global lts
安装 v16 的Node.js
pnpm env use --global 16
安装 Node.js 的预发行版本
pnpm env use --global nightly
pnpm env use --global rc
pnpm env use --global 16.0.0-rc.0
pnpm env use --global rc/14
安装最新版本的 Node.js：
pnpm env use --global latest
使用 codename 安装 Node.js 的 LTS 版本：
pnpm env use --global argon
remove, rm
移除指定版本的 Node.JS.
用法示例：
pnpm env remove --global 14.0.0
list, ls
列出本地或远程可用的 Node.js 版本。
输出本地安装的版本：
pnpm env list
输出远程可用的 Node.js 版本：
pnpm env list --remote
输出远程可用的 Node.js 16 版本：
pnpm env list --remote 16