生产环境Webpack构建Node.js服务：哪种配置方案性能与硬件占用最优？

问题1：生产环境下，为追求最佳性能与最低硬件占用，是否应排除node_modules目录？ #

直接给结论：必须排除！ 这是生产环境构建Node.js服务的标准操作，几乎没有例外。

为啥这么说？

• 第三方依赖（node_modules中的内容）基本都是已经编译完成的生产就绪代码，Webpack再对它们进行转译、打包纯粹是做无用功——既拖慢构建速度，又平白消耗CPU和内存资源。
• 排除node_modules后，Webpack需要处理的文件量会大幅减少，构建时间能快一大截，同时也降低了构建过程中的硬件负载。
• Node.js本身具备完善的模块解析能力，直接用原生require加载依赖即可，完全不需要Webpack将其打包进bundle，反而能利用Node的模块缓存机制，提升服务启动和运行时的加载速度。

当然也有极端例外：如果某个依赖使用了你的Node版本不支持的ES6+语法，你可以单独将这个依赖加入Webpack的处理范围，而非保留整个node_modules。

问题2：方案一vs方案二，哪个更利于性能与硬件使用？ #

毫无疑问方案一完胜方案二，不管是构建性能、运行时表现还是硬件占用，方案一都具备碾压级优势：

构建阶段 #

• 方案一中，借助webpack-node-externals插件排除node_modules后，Webpack的工作量直接锐减，构建速度大幅提升，CPU和内存占用也会显著降低。而方案二要打包所有node_modules内容，文件量巨大，不仅构建缓慢，还可能因内存不足出现构建崩溃的情况。
• 方案一的构建产物体积小巧，部署时传输和存储成本更低；方案二的bundle会异常庞大，部署麻烦的同时，运行时加载速度也会变慢。

运行阶段 #

• 方案一中，Node.js直接加载node_modules里的生产依赖，能利用Node的模块缓存机制，第一次加载后后续请求速度会明显提升；且依赖都是独立模块，出现问题时排查更方便。
• 方案二将所有内容打包成单个文件，运行时需要先把整个大bundle加载进内存，内存占用会大幅升高，一旦出现问题，很难快速定位到具体的依赖模块。
• 方案一使用npm install --production仅安装生产依赖，减少了磁盘占用；方案二即便不安装依赖，Webpack也会把所有依赖打包进bundle，磁盘占用反而更高。

维护层面 #

• 方案一的配置符合Node.js项目的常规实践，团队成员更容易理解和维护；方案二的打包方式违背了Node的模块机制，后续升级依赖、排查问题都会异常繁琐。

内容的提问来源于stack exchange，提问作者Bram z