Webpack编译耗时与总完成耗时差异过大的原因咨询

嘿，这个问题戳中了很多人用Webpack时的疑惑点！我来给你拆解几个最常见的原因：

• 前后置脚本的额外耗时
  很多项目的package.json里会配置prebuild、postbuild这类钩子脚本——比如编译前清理旧的dist目录、跑ESLint代码检查、执行单元测试，编译后可能还要做资源压缩、上传CDN之类的操作。这些操作的时间都会被算在最终的Done in 20.29s里，但Webpack本身只统计自己核心编译流程的7848 ms。举个例子，如果你的prebuild脚本跑测试花了10秒，那总时间自然就比编译时间长很多。

• Webpack插件的后续任务
  有些插件在Webpack核心编译完成后，还会继续执行额外工作：比如copy-webpack-plugin要把静态资源复制到输出目录，html-webpack-plugin生成HTML后可能还要做压缩、注入动态资源路径的处理，或者mini-css-extract-plugin单独处理CSS文件的打包。这些插件的操作不在Webpack标注的“compiled”时间范围内，但会占用总进程的时间。

• 磁盘IO的延迟
  如果你的项目产出大量chunk文件，或者使用的是机械硬盘（HDD），Webpack编译完成后把文件写入磁盘的过程可能会很慢。这部分写入磁盘的耗时不会被算进Webpack的编译时间里，但会包含在总完成时间中——毕竟整个进程要等所有文件都写完才会结束。

• Node.js事件循环的收尾工作
  Webpack标记“compiled successfully”时，只是它的核心编译流程结束了，但Node进程可能还在处理一些异步任务：比如输出日志到终端、清理临时文件、处理一些插件的异步回调。这些收尾工作会让总时间拉长，但Webpack已经认为自己的任务完成了。

• 包管理器的额外开销
  如果你是通过npm run build或者yarn build启动Webpack，包管理器本身的启动、加载环境变量、执行全局钩子等操作，也会占用一部分时间。这部分时间同样算在总Done时间里，但和Webpack的编译流程无关。

内容的提问来源于stack exchange，提问作者Ivan Adanenko