其实也不用每次都安装node_modules，直接使用软连接即可：
windows 使用mklink /j node_modules %APPDATA%Roaming
pm
ode_modules
linux使用ls -s node_modules %APPDATA%Roaming
pm
ode_modules
nodejs中package.json中的依赖必须每个项目都有自己的node_modules文件夹，而无法在多个项目之间共用一套node_modules（像Java中的Maven那样）。
依赖管理是每个现代语言的标配。依赖管理和打包工具是两个概念，npm是依赖管理，webpack是打包工具。
在Java中，maven既能实现依赖管理又能实现打包。
何为依赖管理？
依赖管理说白了就是构建一个有向无环图。项目A依赖项目B，项目B依赖项目C，那么当你的项目依赖A的时候，依赖管理工具会自动让你的项目依赖B和C。
要想构建有向无环图，最关键的是要将项目转化为有向无环图中的结点。所以对于项目往往有description，作者信息，版本信息等额外信息。
依赖管理最难解决的问题就是版本问题。库A依赖库B，库C也依赖库B，但是库A跟库C所依赖的库B不是同一版本，如果库B的这两个版本兼容还好，如果不兼容就坑大发了，这是无解的问题。
下面说说Java，Python，Node三种语言中的依赖管理。
- Java中的Maven仓库在开发者电脑上是全局的，所有项目的依赖都集中存放在本地仓库中。每个项目都有pom.xml指明依赖本地仓库中的哪些库。
- Python中的pip跟maven很像，在开发者电脑上也是集中存放包，但是它不存在版本问题。也就是说，在你的电脑上每个python库都只有一个版本。既然如此，当你依赖某个库的时候，就无需指明版本号，直接引用包的名称就可以了。
- Node中的依赖如果你不写package.json，那么依赖的就是全局的库；如果写了package.json，就会把所有依赖下载到node_modules文件夹。
Node这种node_modules文件夹的方式有利有弊。
最明显的坏处是：
- 每次都需要安装依赖，费流量，网速慢时很费时间
- 浪费磁盘空间，每个node_modules中包含的工具很多，动辄20M
最明显的好处是：
- 使用package.json安装好之后，node_modules文件夹中没有版本信息，从而package.json可以删掉了。
移动/复制/打包项目比较简单，对于开发、部署都有好处 - 对于设计npm的人来说，这是最省事的包依赖方法。这就好比maven安装依赖之后自动将jar包安装到项目的lib里面。
- 随意改代码。安装在node_modules里面的东西，你可以随便改，无需担心对其它项目的影响。在Java中使用maven管理项目时，如果想要定制某个库，就需要更改这个库的源代码，这时就需要把这个库的源代码复制到项目中，跟node_modules是一个道理。npm的设计者大概认为：前端都是经常修改库的源代码的。
我认为不同语言对于依赖的定位不同。Java中的库是严谨的库，Python中的库是玩具一样、随手写就的库，Node里的库是代码片段一样的库。Node里面的库既然定位就是代码片段，那么当然要将代码片段跟你的项目放在一起了，这样才方便你修改这些代码片段。可是随着时间推移，node中的库越来越大、越来越严谨，这种对待代码片段的方式就有些不好了。
总结：这是一种设计，这种设计有利有弊。
以下是知乎上的回答片段：
全局依赖的唯一好处就是省了硬盘空间。这种省毫无意义。首先如果你要为几十几百兆的硬盘空间斤斤计较，那么也许你已经穷得不适合做开发。其次如果需要支持全局多版本也省不了多少。至于有人说的，每次npm install时间太长，我认为这也不是个事。npm install又不是天天搞，而且只是第一次全新checkout的时候比较慢，以后都是增量更新。实在嫌慢（比如因为防火墙的原因），可以把node_modules一起提交到git里去。
其实我觉得完全可以做成全局的，依赖模块都装到公共目录，每个项目在 npm install 时用符号连接把每个模块对应的版本目录连过来，或者干脆就在 require() 时去全局的模块目录里去找，这样也不麻烦。实际上我团队就包了这样一个命令，安装时是全局安装，项目 init 时符号连接过来，很省时间和空间。但 npm 没有这么做，我觉得一是在一开始没考虑到，后面也就不好改了。实际上就连 node_modules 模块多层嵌套导致路径过长的问题，也是一开始设计时没考虑周全，到了 npm3 才改。