最新纯干货，下载某个依赖（eg:sqlite3、ffi-napi、node-sass等）出现node-gyp错误？终极解决方案来了

问题背景

拉取某个项目yarn or npm i 下载依赖可能会出现 node-gyp install or node-gyp build or node-gyp rebuild 失败的错误，然后你就会去百度疯狂查询甚至用上了GPT,但是未必就会解决，如果你是通网络的情况下，可能配一下镜像地址就能搞定，但如果你是不通网络或者黑白名单制，只允许npm org,或 yarn org才能通过，那么你的依赖可能会从github上等地址下载某个依赖，导致直接安装失败。

安装环境

• 内网黑白名单网络
• linux node

原因分析

除了上面说的网络地址不通外可能你还需要注意其它问题，比如node-gyp 需要 合适的 python环境，比如python2 python3 make 适合你的node版本等需要提前准备好，基础node-gyp运行环境问题你可以通过其它方式查询到。
但为什么很多库都需要这个插件呢，因为这些库都需要利用调用C调用的能力，或者去转换编译成适合你本地环境的代码，理论上如果你通网络他就会去下载预编译好的node-headers来构建，则不会出问题，好了经过分析，你现在也许有了方向，比如我能不能把这个node-headers准备好或者看看报错信息准备下其它环境。

解决方案

方案1

首先全局安装一下node-gyp npm i -g node-gyp最终你就会查找这个node-headers放在哪里合适呢，网上的帖子就会告诉你
Linux: 解压这个node-headers.tar.gz 到 ~/.cache/node-gyp/14.20.0下，你是什么版本的node就在这个 ~/.cache/node-gyp/**.**.**下创建这个文件夹 把解压的文件详情 复制到里面去
Windows: 同理 应该是 C/User/admin/xx 具体的可以根据自己的电脑查找一下或者去网络上查询一下,也放置在缓存目录下
然后你再尝试一下下载项目的依赖看看是否可行，如果失败的话，可能会将你手动设置的缓存版本删除掉记得备份一下。

方案2

先准备好方案1的环境，就假装它会主动读取，然后我们着手第二步。
使用 npm i --ignore-scripts 命令下载依赖,这个会忽略个别依赖的模块的脚本运行，这样你下载就不会报错，然后你就直接编译项目或者启动项目 看看报错信息， 比如 xx moudle not found 那基本上就知道 是哪个依赖需要执行其它脚本命令，假设这里你已经知道了是哪个依赖报错的话，那你就不需要去编译或者启动项目来根据错误判断是哪个模块了。
然后我们进入 举例（eg:sqlite3）
node_moudus/sqlite3目录下，我们查看一下依赖的源码，第一步查看是否有binding.gyp文件，再看一下 package.json 文件中的scripts选项, 里面是否有 build install等命令，是不是跟你下载依赖报错时提示的错误命令一样，那么我们就可以进行下一步操作了：

1. 在依赖的当前目录下执行 npm run build 命令 , 查看一下报错信息，如果提示./node-vxx.xx.xx-headers.tar.gznot found,则证明把这个依赖放到它的同级目录下就会被读取的，所以我们将错误提示的`node-vxx.xx.xx-headers.tar.gz``复制过来。
2. 再次执行 npm run build 命令则会成功编译，编译出你本地可执行的代码。
3. 返回到你的项目编译代码，运行项目，然后你就会发现正常运行起来了。

总结

报错不可怕，可怕的是不报错，网上的热门帖子都是很久之前的，只能作为参考 不同的依赖版本,读取方式也不一样 需要灵活调整或者看看源码 issue ，大概的解决方式就是它需要什么我们就去准备什么，满足它的执行环境，这样就能保证不会报错，就像过关一样的去解决它， 在我的代码运行环境中有两个依赖出现了这个错误，都是通过上述的方法解决的，有时候想要去规避也许是一个很好的解决方案，但是如果避无可避呢，只能去解决它,前端的node-sass 运行应该是同理，所以大致也能通过上述的思路去解决。