什么是幻影依赖
什么是幻影依赖呢？这个概念其实非常容易理解。假设我们的项目依赖一个包A，这个A呢，又依赖包B，也就是我们间接依赖了包B，但是这样，在我们的package.json文件中，dependencies中，就只声明了A这个包。
但是，大家都知道，使用npm管理的node_modules文件夹中，所有的依赖都是拍平放置的，也就是虽然包A依赖包B，但是，在文件夹中，包A和B是平级放置的，就像这样：
而我们使用import去引入依赖的时候，只要node_modules下有，就可以直接引入进来，也就是：
js
// 尽管我们的package.json中没有声明package_B
import B from "package_B";
console.log(B)这里的B就是幻影依赖。如果我们这样写了代码，将来如果包A进行了升级，它依赖的B也升级了，那么就有可能出现问题。或者，我们的一个开发依赖，它间接依赖了包B，我们还直接在代码中去import了B，开发的时候没问题，但是打包上线之后，开发依赖不会进入最终包，我们依赖的B就没了，这样就出问题了。
那么npm为什么会用这种方式来放置包呢？只要我们把node_modules的结构改成这样的，各自的间接依赖放在各自自己的文件夹下，就没这个问题了吧：
这样，各自的间接依赖被放置在各个包自己的文件夹下，不放在顶层，使用import直接去导入找不到包B，这样不就没问题了？但是，这里存在一个矛盾：依赖是图，但是文件它是树，图结构和树结构是不兼容的：
其实，早期的npm就是这么干的（各自的间接依赖被放置在各个包自己的文件夹下），但是这样有一个问题：如果不同的包，都间接依赖这个包B，那么，这个包岂不是会被重复安装非常多次，造成完全不必要的磁盘空间占用？所以，npm借鉴了yarn的模式，将所有的包拍平，全安装在顶层，这样，就可以解决一个依赖被重复安装的问题了。
解决幻影依赖
那幻影依赖如何解决？pnpm是这样做的：将包安装单独的store中，node_modules下的结构依然是各自间接依赖放各自文件夹，但是，这里的node_modules中，放的不是包的本体了，而是各自的"快捷方式"，包的本体在单独的store中存着。这样，既避免了幻影依赖，也解决了包的重复存储的问题。
这个"快捷方式"，其实是一个比较通俗的说法，具体来说，应该叫链接，分为两种方式：硬链接和软链接。
因为操作系统中，你看到的文件其实是文件系统中的元数据，每个文件对应一个inode，该inode记录了文件属性并包含指向存储文件数据块的指针，这个指针指向磁盘中的某块空间区域，也就是你的文件数据真正所在的地方。
硬链接是创建一个新的指针，同样指向原来指针指向的区域，这样对旧指针的操作不会影响新指针。软链接则是创建一个指向原来指针的指针，这样，对旧指针的操作会影响到新指针。也就是硬链接创建的是相互独立的内容，你把A删了，B一样可以用，但是软链接就不行，把A删了，B就没法用了，指针就丢失了。