前端构建工具在开发阶段频繁运行，每次打包都消耗 CPU、内存和电能。把这部分能源消耗降下来，不仅能让开发机更安静，也能减少团队整体碳足迹。Webpack 5 虽然没有把能源效率作为独立的宣传口号，但它在持久化缓存、模块消除、标识符生成等底层机制上的改进，确实带来了显著的能耗下降。这些优化同时作用于构建期与运行期，下面从几个关键特性展开。
持久化缓存：构建期能耗的显著下降
Webpack 4 的默认缓存仅存在于内存中，每次冷启动构建都要重新解析所有模块、遍历依赖图、执行 loader 转换，这些操作会长时间占用 CPU。Webpack 5 引入的 filesystem 持久化缓存，可以把模块依赖关系、编译产物和转换结果写入磁盘，下次构建时直接复用。磁盘读取速度远快于重新计算，而且省去了大量重复的字符串处理和 AST 分析。
启用方式很简单，在 webpack.config.js 中设置 cache.type 为 filesystem 即可。需要注意 buildDependencies 的作用：当配置文件自身发生变化时，缓存必须失效，否则会使用过期的构建结果导致错误。
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
config: [__filename]
}
}
};
实际项目中，一个包含数千个模块的中型应用，首次冷启动构建可能耗时 40 到 60 秒，启用持久化缓存后第二次构建通常只需要 2 到 5 秒。构建时间缩短意味着 CPU 高负载窗口大幅收窄，风扇噪音和功耗同步下降。对于频繁修改代码并触发 watch 或 dev server 重新编译的场景，累积下来的节能效果非常可观。此外，Webpack 5 对缓存文件的写入做了增量优化，不会因为缓存本身引入过多的磁盘 I/O 开销。
Tree Shaking 与作用域提升：降低产物运行能耗
构建工具的能耗不仅体现在开发机上，最终打包出来的 JavaScript 文件在用户设备上运行也会消耗电量。Webpack 5 对 ES module 的静态结构分析比 Webpack 4 更精确，能够识别并删除未被使用的导出，也就是常说的 Tree Shaking。同时，作用域提升会把多个模块合并到同一个函数作用域中，减少模块包裹函数和闭包调用，从而降低浏览器解析和执行脚本时的 CPU 与内存消耗。
Tree Shaking 需要配合 optimization.usedExports 和 optimization.sideEffects 使用。如果项目的 package.json 中声明了 sideEffects: false，Webpack 可以更激进地删除没有副作用的模块，进一步缩小产物体积。
module.exports = {
mode: 'production',
optimization: {
usedExports: true,
sideEffects: false,
concatenateModules: true,
minimize: true
}
};
以一个引入了大型工具库但只使用其中几个函数的页面为例，未开启 Tree Shaking 时打包产物可能超过 1 MB，开启后可以缩小到 300 KB 以下。体积减小直接带来三方面的能耗收益：网络传输时间缩短、浏览器解析脚本的 CPU 时间减少、移动设备内存占用降低。作用域提升进一步优化了执行性能，因为函数调用次数变少，运行时栈切换开销也变小。这些都是 Webpack 5 能源效率提升的重要组成部分。
长期缓存与确定性 ID：减少重复下载与解析
Webpack 4 默认使用递增的数字作为模块 ID，当模块顺序发生微小变化时，大量 chunk 文件名会随之改变，导致用户浏览器缓存全部失效，需要重新下载整个应用。Webpack 5 默认启用了确定性模块 ID 和确定性 chunk ID，它们基于模块路径等内容生成稳定标识，只有真正发生变化的模块才会影响对应 chunk 的文件名。
配置项 optimization.moduleIds 和 optimization.chunkIds 可以显式设置为 deterministic。同时建议把 runtime 代码单独提取，因为 runtime 中包含了模块加载逻辑，经常因业务代码变化而改变，分开后不会连带 vendor chunk 一起失效。
module.exports = {
optimization: {
moduleIds: 'deterministic',
chunkIds: 'deterministic',
runtimeChunk: 'single'
}
};
长期缓存命中率的提高，意味着用户设备不用频繁下载重复代码，网络请求和脚本解析的能耗随之下降。对于移动端用户来说，这种优化还能减少流量消耗和电池压力。配合 splitChunks 把第三方依赖单独打包为 vendor chunk，可以进一步稳定缓存边界，因为业务代码更新时第三方库通常保持不变。
module.exports = {
optimization: {
splitChunks: {
chunks: 'all',
cacheGroups: {
vendor: {
test: /[\\/]node_modules[\\/]/,
name: 'vendors',
chunks: 'all'
}
}
}
}
};
能效测量与调优：找出高耗能环节
想要持续优化构建能效，首先需要知道时间花在哪里。使用 speed-measure-webpack-plugin 可以测量每个 loader 和 plugin 的耗时，识别出高耗能环节；使用 webpack-bundle-analyzer 可以查看产物体积构成，找出体积异常的依赖。
安装这两个工具后，可以把 Webpack 配置用 SpeedMeasurePlugin 包裹起来，运行构建后查看输出报告。
const SpeedMeasurePlugin = require('speed-measure-webpack-plugin');
const smp = new SpeedMeasurePlugin();
module.exports = smp.wrap({
// 原有的 webpack 配置
});
测量结果可能显示某个 loader 耗时特别长，这时可以考虑替换为更快的实现、开启缓存、或者缩小其处理范围。但要注意，盲目引入大量并行 worker 并不一定能降低总能耗。虽然并行可以缩短构建时间，但瞬时功耗会上升，而且进程间通信本身也有开销。如果目标是能源效率而不是单纯的构建速度，应该优先消除重复计算、优化依赖图和减小产物体积，再考虑有限度的并行。将测量数据与功耗监控结合，才能找到时间与能耗的最佳平衡点。