这个问题简直是前端圈的“共同回忆”——谁没在某个加班的深夜，对着终端里的奇怪报错，咬牙删掉node_modules然后敲下npm install呢？哪怕npm从1.0到现在迭代了这么多版本，这个“偏方”依然好用，主要有这么几个原因：

• 依赖树的天生复杂性
  npm的依赖是嵌套式的，不同包可能依赖同一个基础包的不同版本，早期npm的依赖解析算法（比如3.x之前的非扁平依赖）很容易让依赖树变得臃肿混乱。哪怕后来有了package-lock.json或yarn.lock来锁定版本，偶尔还是会出现锁文件和实际安装的依赖不匹配的情况——比如手动修改了package.json但没更新锁文件，或者某些包的版本范围太宽松导致拉到了意料之外的版本。删node_modules相当于彻底清空本地的依赖快照，让npm重新按照锁文件（或package.json）构建出干净的依赖树。

• 缓存与安装残留的坑
  npm会把下载过的包存在本地缓存里（默认在~/.npm目录），有时候缓存的包可能损坏、或者是旧版本的残留。虽然npm cache clean也能清缓存，但很多时候你不确定是不是缓存的问题，而删node_modules是直接把本地已经安装的所有依赖清空，重新拉取的过程中如果缓存有问题，npm会自动重新下载完整的包，相当于连带着解决了缓存的潜在问题。

• 编译类包的环境不兼容
  像node-sass、canvas这类带有二进制编译的包，安装时会根据你的Node版本、操作系统生成对应的编译产物。如果之后你升级了Node版本、或者换了系统环境，旧的编译产物就会失效，出现各种奇怪的运行时错误。有时候只重新安装单个包可能没触发完整的重新编译流程，但删node_modules后重新install，会让所有需要编译的包都重新执行postinstall脚本，生成适配当前环境的产物。

• 历史遗留的设计债务
  从npm 1.0到现在，团队确实修复了无数bug，但依赖管理本身是个极其复杂的问题——比如早期的npm没有锁文件，依赖版本完全靠package.json的范围来解析，导致不同环境安装的依赖可能不一样；后来虽然加了锁文件，但一些边缘场景（比如包的依赖声明有冲突、私有包的版本问题）还是会出现难以排查的问题。而删node_modules是最直接的“硬重置”，不需要去排查具体是哪个依赖出了问题，直接回到初始状态，对很多开发者来说，这比花几个小时debug要高效得多。

说白了，这个方案之所以成为业内共识，本质上是因为依赖管理的复杂度太高，排查单个问题的成本远高于“重置重来”的成本——毕竟rm -rf node_modules && npm install敲起来快，而且大概率能解决问题。

内容的提问来源于stack exchange，提问作者Adam Zielinski