开门见山，npm install 大概会经过上面的几个流程，本篇文章来讲一讲各个流程的实现细节、发展以及为何要这样实现。 嵌套结构 我们都知道，执行 npm install 后，依赖包被安装到了 node_modules ，下面我们来具体了解下，npm 将依赖包安装到 node_modules 的具体机制是什么。 在 npm 的早期版本， npm 处理依赖的方式简单粗暴，以递归的形式，严格按照 package.json 结构以及子依赖包的 package.json 结构将依赖安装到他们各自的 node_modules 中。直到有子依赖包不在依赖其他模块。 举个例子，我们的模块 my-app 现在依赖了两个模块：buffer、ignore： { "name": "my-app", "dependencies": { "buffer": "^5.4.3", "ignore": "^5.1.4", } } ignore是一个纯 JS 模块，不依赖任何其他模块，而 buffer 又依赖了下面两个模块：base64-js 、 ieee754。 { "name": "buffer", "dependencies": { "base64-js": "^1.0.2", "ieee754": "^1.1.4" } } 那么，执行 npm install 后，得到的 node_modules 中模块目录结构就是下面这样的： 这样的方式优点很明显， node_modules 的结构和 package.json 结构一一对应，层级结构明显，并且保证了每次安装目录结构都是相同的。 但是，试想一下，如果你依赖的模块非常之多，你的 node_modules 将非常庞大，嵌套层级非常之深： 在不同层级的依赖中，可能引用了同一个模块，导致大量冗余。 在 Windows 系统中，文件路径最大长度为260个字符，嵌套层级过深可能导致不可预知的问题。 扁平结构 为了解决以上问题，NPM 在 3.x 版本做了一次较大更新。其将早期的嵌套结构改为扁平结构： 安装模块时，不管其是直接依赖还是子依赖的依赖，优先将其安装在 node_modules 根目录。 还是上面的依赖结构，我们在执行 npm install 后将得到下面的目录结构： 此时我们若在模块中又依赖了 base64-js@1.0.1 版本： { "name": "my-app", "dependencies": { "buffer": "^5.4.3", "ignore": "^5.1.4", "base64-js": "1.0.1", } } 当安装到相同模块时，判断已安装的模块版本是否符合新模块的版本范围，如果符合则跳过，不符合则在当前模块的 node_modules 下安装该模块。 此时，我们在执行 npm install 后将得到下面的目录结构： 对应的，如果我们在项目代码中引用了一个模块，模块查找流程如下： 在当前模块路径下搜索 在当前模块 node_modules 路径下搜素 在上级模块的 node_modules 路径下搜索 ... 直到搜索到全局路径中的 node_modules 假设我们又依赖了一个包 buffer2@^5.4.3，而它依赖了包 base64-js@1.0.3，则此时的安装结构是下面这样的： 所以 npm 3.x 版本并未完全解决老版本的模块冗余问题，甚至还会带来新的问题。 试想一下，你的APP假设没有依赖 base64-js@1.0.1 版本，而你同时依赖了依赖不同 base64-js 版本的 buffer 和 buffer2。由于在执行 npm install 的时候，按照 package.json 里依赖的顺序依次解析，则 buffer 和 buffer2 在 package.json 的放置顺序则决定了 node_modules 的依赖结构： 先依赖buffer2： 先依赖buffer： 另外，为了让开发者在安全的前提下使用最新的依赖包，我们在 package.json 通常只会锁定大版本，这意味着在某些依赖包小版本更新后，同样可能造成依赖结构的改动，依赖结构的不确定性可能会给程序带来不可预知的问题。
原文：https://www.cnblogs.com/feiji666/p/14336572.html