由于构建机器和本地开发的环境可能不完全一致，所以在本地能正常开发运行的前端项目，在构建机器上构建有可能是失败，且部分错误难以排查复现，导致阻塞发布流程，甚至在到了生产环境才发现相关的问题。下面做一些踩坑case的分享，希望能帮忙大家减少构建出错的概率，提升效率和稳定性。
报错case
下载某个包超时，网络连接失败
明明本地执行npm install xxx包是成功的，但是构建机器会报错
比如：
● 安装html2canvas，报某个地址为github.com的资源下载失败
● 安装v-viewer，报缺失viewerjs
2、 安装某个包报node-gyp依赖安装失败
这种情况可能在本地npm install的时候就已经很容易报错了，解决方法百度了一堆也挺麻烦的，就算本地安装成功了，不代表构建机器能成功。
典型的以安装sass报错最为常见。
解决以及避免方案
1、 npm设置统一仓库源
为了统一所有网络资源环境，应每台开发电脑都统一设置相同的仓库源，且保持和构建机器一致
arduino
npm config set registry https://registry.npm.taobao.org/2、 package.json和package-lock.json要一起提交到git仓库
package.json的作用是声明该npm项目的基础信息以及使用了哪些包，但是存在两个问题：一是没有100%精准锁定某个包的具体版本。二是没有锁定依赖包的内部依赖的版本，package-lock.json就是为了补充完整这两者信息而存在。有了这两个配置文件，就能保证不同环境执行npm install能下载100%相同的node_modules文件，消除差异。
● 注意检查.gitignore文件不要写上package-lock.json
3、 npm针对特殊包配置指定的下载镜像地址
这种情况是针对一些特殊的三方包（npm设计的历史遗留问题），比如说html2canvas依赖的canvas有特殊下载路径，electron的部分内部依赖有特殊下载路径，这些路径往往因为没有梯子或者网络权限的问题导致下载失败。针对这些特殊的依赖，可以增加特定的配置。
ini
// 配置canvas相关下载源canvas_binary_host_mirror = "https://registry.npmmirror.com/-/binary/canvas"4、 针对npm配置不要设置在本地电脑，新建.npmrc配置文件且上传到git
所有的npm set config的操作，都只是为了解决本地的开发环境问题，而没有做到全平台统一。.npmrc文件是存在于根路径，只作用于本项目的npm配置，以上方案3的配置就是应该写在.npmrc文件里，与package.json同级
5、 尽量避免使用一些依赖非JS环境编译的包，如使用，请做好踩坑准备。
典型的就是sass这个css预处理器，相信百度一下就能看到一堆人求助各种安装报错。node-sass是依赖python2， window c++环境编译的，为了安装成功，本地环境不仅要安装齐全所有的环境，且要保证npm，node-sass，python2，c++这多者的版本要对应符合才不会报错。解决这种问题有三个思路：
● 一是保证测试，仿真和生产的构建机器都具备符合版本的python和c++环境，且与每个开发电脑的环境要一致。
● 二是放弃使用sass，改用其他css预处理器，例如less。
● 三是开源社区推出了dart-sass代替node-sass，采用纯JS编译，减少了安装的心智负担。
6、 发布前，本地尝试删除node_modules, 执行构建命令，验证结果
这样做能避免两个问题，一是npm run dev成功，不代表npm run build不会失败；二是确认npm install命令最终是可以执行成功的
7、 本地node版本和构建机器node版本管理问题
对于开发本地node版本的管理，这里推荐一个工具叫nvm，可自由安装和切换多个不同的node版本在本地。
nvm文档手册 - nvm是一个nodejs版本管理工具 - nvm中文网
至于构建机器，可采用两种方案，一是可创建多个不同镜像，不同项目可配置使用不同的镜像构建；二是同一个镜像也是采用nvm的方案，在构建命令里可以切换指定的node版本。
总结
总的来说，以上方案就是为了做到：
- 统一所有开发机器和构建机器的配置，以达到一致的构建环境。
- 针对特殊的三方包谨慎使用，一般社区会有踩坑方案。