生产验证
全局安装 brew install pnpm
以我自己基于vue-cli封装的一个移动端项目vue-template为例
github 地址如下
基于vue-cli二次封装的移动端框架，vue3 +vue-cli4 + webpack5 + 多入口打包 + 自动生成项目模版 + pinia + 数据持久化 + 路由动画 + axios二次封装
npm i 之后
查看node_modules 体积 293M
du -h -s node_modules 293M node_modules
查看package-lcok.json中重复文件，以postcss为例，一眼就看到了两个版本的postcss版本，
查看node_modules只有一个版本的postcss 包会被提升，其他版本的就会被重复下载
pnpm i 之后
查看node_modules 体积 251M
du -h -s node_modules\ 251M node_modules
切换到node_modules目录下，查看所有文件信息
cd node_modules ls -alh
以axios库为例，只有37B，只是一个快捷方式，axios 软链接指向 .pnpm/axios@0.26.1/node_modules/axios
切换到.pnpm 目录下，查看所有文件信息
cd .pnpm ls -alh
我们看到postcss三个版本文件夹，说明现在项目里依赖三个版本的postcss
切换到postcss@7.0.39目录，查看文件信息
cd postcss@7.0.39/node_modules/postcss stat -x package.json
值得关注的属性有两个，一个是Links，表示硬链接个数，一个是Inode
我们可以通过Inode 去查询所有的硬链接
find . -inum 8177610
可以看到，在全局Library/pnpm/store/下对应的文件目录
4条记录 也对应了 links：4
对比
对比发现，当一个项目时，两者差距不大。
举一个极端的例子，当有10个相同项目时，npm 的node_modules 将达到2930M，将近3个G，而pnpm 依旧能保持 全局253M的体积，此时优势已经很明显了。
我们在业务开发时，其实一般都通用的模版，所以项目的依赖基本上一致，我觉得pnpm还是非常好的。
全局安装目录 pnpm-store的目录结构
pnpm └── store └── v3 └── files ├── 00 - cd3e571524c095736 - 02a74db92f0368580 ├── 01 ├── 02
上图是我们全局目录下pnpm 的目录结构。
我们在全局目录里存放的不是npm 包的源码，而是hash文件，这里采用了基于文件内容寻址方案。
简单来说就是文件内容被加密成了64位hash值，hash值都是唯一的，如果文件内容不变，hash 值也不会变。
这个非常适合npm的安装包，一般来说，依赖包的更新都是向下兼容的，两个版本的包差别只是部分，而我们使用hash存储，会根据文件内容变化，只会存储变化的部分，相同的部分，生成的hash不会变，只存储一份就够了，一定程度上，也节省了磁盘空间。
pnpm 弊端
调试问题
所有项目引用的包都在全局一个地方，如果想对某个包进行调试，其他项目正好引用了，本地运行也会收到影响。
兼容问题
symlink 即软连接的方式可能会在 windows 存在一些兼容的问题，但是针对这个问题，pnpm 也提供了对应的解决方案：在 win 系统上使用一个叫做 junctions 的特性来替代软连接，这个方案在 window 上的兼容性要好于 symlink
我没有windows电脑，没有实验过，这条是从官网挪过来了。
我理解的是window下也是可以使用的，pnpm 已经帮我们做了兼容，只是没有使用软链接的方案。
