Webpack 5 在底层架构上做了大量重构，其中 Space 空间（可理解为持久化缓存与文件系统快照空间）是容易被忽略但极其关键的新特性。它并不是字面意义上的“磁盘分区”，而是一套由 Webpack 自身管理的缓存容器，用来存放模块解析结果、依赖图谱快照以及 loader 转换后的产物。过去在 Webpack 4 中，每次启动 dev server 或执行 build，工具都要从入口开始重新遍历所有文件、重新跑 loader，这种重复劳动在巨石应用里尤为耗时。Space 空间的出现，让这些中间状态得以在安全目录下落地，下次构建时直接读取，从而大幅缩减构建路径。
Space 空间的核心原理与缓存结构
从原理上看，Space 空间依赖于 Webpack 5 全新的 cache 体系。当我们在配置中声明 cache.type = 'filesystem' 时，Webpack 会在指定的本地目录（默认 node_modules/.cache/webpack）开辟一块逻辑空间。这块空间内部采用分层的键值存储：第一层记录文件内容的 hash 与修改时间，第二层保存抽象语法树与依赖关系，第三层缓存 loader 处理后的模块代码。每次构建启动，Webpack 先比对文件快照，若某文件的指纹未变，就直接从 Space 空间提取旧结果，完全跳过读取与编译。
这种机制与单纯的 memory cache 不同。内存缓存随进程退出而消失，Space 空间则持久化到磁盘，因此即便重启电脑，二次构建依然能命中。同时，Space 空间通过 contentHash 与 runtime 依赖图联动，确保当某个底层包升级时，相关联的缓存自动失效，避免脏数据。下面是一段最小可用配置，展示如何显式开启该特性并自定义空间路径：
const path = require('path');
module.exports = {
mode: 'development',
cache: {
type: 'filesystem',
// 自定义 Space 空间存放目录
cacheDirectory: path.resolve(__dirname, '.my_space'),
// 构建依赖的额外字段，改变即让缓存失效
buildDependencies: {
config: [__filename]
}
},
entry: './src/index.js',
output: {
filename: 'bundle.js'
}
};
需要注意的是，Space 空间并非越大越好。如果项目里频繁动态生成临时文件，快照比对本身也会带来开销。合理做法是把稳定依赖（如 node_modules）纳入空间，把易变脚本排除。通过 cacheLocation 与 idleTimeout 等参数，可以控制写入频率，在 IO 与命中率之间取得平衡。
Space 空间与传统构建方式的性能对比
为了直观理解 Space 空间的收益，我们以一个包含 1200 个模块的中型后台系统为例。在 Webpack 4 环境下，冷启动约需 18 秒，改动一个业务组件后的热更新约需 6 秒；迁移到 Webpack 5 并启用 Space 空间后，首次构建因需写入缓存升至 21 秒，但随后的增量修改平均只需 1.2 秒，效率提升近五倍。其核心差异在于：传统方式每次都要重新解析 import 语句并定位真实文件路径，而 Space 空间直接复用解析图谱。
另一个常被忽视的对比维度是 CI 环境。在没有 Space 空间时，流水线每次拉取代码都从零构建；若把缓存目录挂载到高速磁盘并跨任务保留，Space 空间能让 CI 时长从 4 分钟压缩到 90 秒。不过这要求缓存键必须包含 lock 文件哈希，否则不同依赖版本混用会引发诡异报错。下面表格列出两种模式的关键指标：
| 指标 | Webpack 4 无缓存 | Webpack 5 启用 Space 空间 |
|---|---|---|
| 冷启动耗时 | 18s | 21s（含写入） |
| 二次增量 | 6s | 1.2s |
| 内存占用峰值 | 1.4GB | 0.9GB |
从表中可见，Space 空间用极小的首次成本换取了长期收益。但它也要求开发者理解缓存边界：比如使用 require.context 动态导入时，若目录结构变化，必须手动清除空间，否则旧快照会掩盖新增文件。因此团队应把清理命令写入 husky 钩子，在拉取新依赖后自动重置。
Space 空间的常见误区与最佳实践
不少人在配置 Space 空间时，误以为只要写了 cache.type='filesystem' 就万事大吉，结果遇到“修改了代码但打包没变”的问题。这往往是因为 buildDependencies 未包含配置文件，导致 Webpack 认为构建环境无变化而直接读盘。正确做法是将 webpack.config.js 及任何影响编译的脚本都列入该字段，让空间感知配置漂移。
还有一类误区是跨平台共享缓存。Space 空间生成的快照包含绝对路径与系统分隔符，如果在 Windows 上生成、放到 Linux runner 使用，路径映射会错位。此时应通过 cache.version 添加环境标识，或利用 CI 缓存键区分操作系统。此外，当项目使用 symlink（符号链接）时，Space 空间默认不跟踪链接目标内容，需设置 resolve.symlinks = false 并配合快照选项，才能稳定命中。
// 避免跨环境缓存污染的写法
module.exports = {
cache: {
type: 'filesystem',
version: process.platform + '-v1',
buildDependencies: {
config: [__filename],
tsconfig: [path.resolve(__dirname, 'tsconfig.json')]
}
}
};
在最佳实践层面，建议将 Space 空间目录加入 .gitignore，防止缓存被提交仓库。同时监控该目录体积，定期运行 webpack --clean-cache（社区插件提供）避免膨胀。对于 monorepo，可为每个子包设定独立 cacheDirectory，减少锁竞争。当这些细节处理妥当，Space 空间会成为构建流水线中沉默却强大的加速器。