# Rspack 新缓存把磁盘占用压下来了，热构建却慢一点，CI 上值得开吗？

**URL:** <https://www.shiqidu.com/t/topic/1860>\
**Category:** 开发调优\
**Tags:** JavaScript, 前端优化, 前端开发, Node.js\
**Created:** [2026 年10 月 30 日 08:52 UTC](https://www.shiqidu.com/t/topic/1860 "2026-10-30T08:52:00Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

作者： ![shiqidu\_editor](https://www.shiqidu.com/user_avatar/www.shiqidu.com/shiqidu_editor/32/528_2.png) [@shiqidu\_editor](https://www.shiqidu.com/u/shiqidu_editor)\
发布日期： [2026 年10 月 30 日 08:52 UTC](https://www.shiqidu.com/t/topic/1860/1 "2026-10-30T08:52:00Z")

</div>

CI 上的构建缓存要来回搬两趟：构建完打包上传，下一条流水线开头再拉回来解压。目录越大，两头耗得越久，碰上 runner 网络一般，搬运的工夫有时能把省下的编译时间吃掉不少。Rspack 2.3 带的那套新缓存，瞄准的正是占用大、写得慢这两件事。

## 官方给的数字

这些数字都出自 10 月 29 日的官方博客 [Announcing Rspack 2.3](https://rspack.rs/blog/announcing-2-3)，是他们自己的基准测试，换个项目结果会不一样。博客写的是，新缓存让磁盘占用下降约 79%，冷构建时的峰值内存减少约 16%。热构建则稍微慢了一点。

省空间的原因博客也讲了。旧缓存保存整个构建阶段的中间状态，模块之间的关系也一并写进去，文件大，恢复时容易出错。新实现只存单个任务（像一次模块构建）的结果，写盘前的准备工作挪到空闲时段或者最后收尾阶段，不再卡着编译。

## 怎么开

[experiments 配置文档](https://rspack.rs/config/experiments)里，`experiments.newCache` 标着 Stability: Experimental，默认值是 `false`。持久化缓存要这样写：

```js
export default {
  cache: {
    type: 'persistent',
  },
  experiments: {
    newCache: true,
  },
};

```

`newCache` 也能传对象，按阶段开关：`codeGeneration`、`module`、`devtool`、`loader`、`minimize` 默认都是开的，只有 `resolver` 是关的。实验性的东西后面可能改名或调整，升级 Rspack 时留意 changelog，lockfile 里把版本锁住。

## CI 上要多想几步

- 文档写明 production 和 none 模式下 `cache` 默认是 `false`，CI 一般跑生产构建，不显式配置就等于没开缓存，新旧实现都一样。
- 新实现暂不支持 [`cache.portable`](https://rspack.rs/config/cache) 和 `cache.maxAge`。前者让缓存能跨平台、跨路径共用，靠它在多台机器间搬运的项目，眼下还开不了新实现。后者在现有实现里默认清掉 7 天没被访问的缓存目录。切换以后，过期清理大概只能交给 CI 那边的策略。
- 默认存放目录是 `node_modules/.cache/rspack`，CI 里配的缓存路径要对上，key 最好带上 lockfile 的哈希。
- CI 把缓存恢复回来以后跑的那一次，本身就算热构建。磁盘上省下的空间换来上传下载变快，热构建又慢一点，两头能不能抵得过，只有实测知道。

babel-loader、less-loader 这类转换开销大的项目，可以顺带试试单个 loader 的缓存：开了新缓存后，在 `module.rules` 的 use 项里加 `cache: true`。它的失效条件单独计算：整体配置改了，只要这个 loader 自己的输入、选项和依赖不动，结果照样能复用。博客里用 babel-loader 处理约一万个模拟模块，关掉并行 loader 时，开缓存把耗时从 63.8 秒压到 11.2 秒。

## 怎么测

冷跑、热跑各三次：冷跑前清空缓存目录，热跑时保留它。每回记下耗时、峰值内存和占用空间，CI 上再加一项上传下载用掉的时间。Linux 上用 `/usr/bin/time -v` 看 Maximum resident set size，目录大小用 `du -sh`。新旧实现各测一轮，数字摆在一起就好判断了。

测完大致能分成几种情况。缓存目录大、上传下载占了流水线不少时间，或者 runner 内存比较紧的，新实现可以早点上，冷构建时省下的那 16% 峰值在小规格机器上也有用。依赖 `cache.portable` 跨机器共用缓存的，等官方补上支持再说。缓存本来就小、流水线大部分时间花在测试上的，换不换差别不大，没必要给自己加一个实验开关。

本地开发也可以单独看。dev 模式下 `cache` 默认就是内存缓存，要不要在本地也开持久化加新实现，看你平时重启 dev server 的频率。一天要来回折腾好多回的话，热构建慢的那一点会天天碰到，可以先只在 CI 的配置里打开。

这个版本还换上了 SWC Next 解析器，跟缓存是两回事，这里不展开。官方说打算在之后的某个小版本里把新缓存设为默认。

有在 CI 上试过的吗，缓存目录实际小了多少？