Nuxt 学习

Appearance

用构建缓存加速 Nuxt 打包 ​

Nuxt 3 的构建速度相比 Nuxt 2 已经快了不少，但在真实的迭代和部署流程中仍有优化空间：很多时候你只改动了数据、内容或服务端路由，前端代码本身根本没变，却每次都要跑一遍完整构建，把该编译的都重新编译一遍。

这在 CI/CD 频繁部署时尤其浪费时间和算力。

如今由 Pooya Parsa（pi0）带来的 nuxt-build-cache 模块把这一能力带回了 Nuxt 3：当检测到源代码没有实质变化时，直接复用上一次的构建产物，跳过重复工作。

安装并启用 build cache 模块 ​

模块的接入方式非常轻量。先安装依赖，再把它加入 nuxt.config.ts 的 modules 列表：

bash
npx nuxi module add nuxt-build-cache
# 或手动安装
npm install -D nuxt-build-cache
ts
// nuxt.config.ts
export default defineNuxtConfig({
  modules: [
    'nuxt-build-cache'
  ]
})

接入几乎是「零配置」的，加上模块即可生效，不需要复杂的参数调优。

如何利用缓存 ​

启用后，运行构建命令时模块会介入判断：

bash
nuxi build

其工作逻辑是：模块会为当前的源代码状态计算一个「指纹（hash）」。

如果本次构建的指纹与上一次缓存的一致（即相关代码没有实质变化），它就直接恢复此前缓存的构建产物，跳过真正的编译过程；若指纹变了，则正常执行完整构建并更新缓存。

第一次构建照常耗时，而在代码未变的情况下再次构建，时间会大幅缩短，因为大部分工作被缓存命中直接跳过了。

为什么该用它 ​

判断集中在重复构建与部署场景：

  • 本地反复构建：调试部署配置、只改了非前端内容时，不必每次重头编译。
  • CI/CD 部署：内容型或数据型站点频繁重新部署，缓存命中能显著缩短流水线时间。
  • 回滚与切换分支：切回此前构建过的状态时，可直接复用缓存产物。

换言之，它的收益与「构建频率」和「代码变动的稀疏程度」正相关，改得越少、构建越频繁，节省越明显。

缓存是怎么工作的 ​

进一步拆解了模块的内部机制，核心在于基于内容指纹的缓存键：

  • 模块收集参与构建的相关文件，计算出一个哈希作为缓存标识。
  • 构建产物（.output / .nuxt 等相关目录）被打包存入缓存目录。
  • 下次构建时先比对哈希：命中则解包恢复，未命中则重新构建并写入新缓存。

这种「指纹 + 产物快照」的设计，本质上和其他构建缓存工具（如打包器的持久化缓存）思路一致，用一次哈希比对的低成本，换取一整轮编译的高成本。

常见案例 ​

  1. 安装模块：npx nuxi module add nuxt-build-cache 或手动 npm install -D。
  2. 注册到配置：在 nuxt.config.ts 的 modules 数组里加入 'nuxt-build-cache'。
  3. 正常构建：照常执行 nuxi build，首次构建生成缓存。
  4. 享受命中：代码未变时再次构建，自动复用缓存、大幅提速。
  5. 在 CI 中持久化缓存目录：把缓存目录纳入 CI 缓存，让跨流水线的构建也能命中。
  6. 变更即失效：改动相关代码后指纹变化，缓存自动失效并重建，无需手动清理。

注意事项 ​

事项说明
收益取决于场景只改数据/服务端路由、前端未变时收益最大；每次都大改则命中率低。
社区模块由 pi0 维护的社区模块，非 Nuxt 内置，接入前留意其维护与兼容状态。
缓存基于指纹缓存键由源代码哈希决定，代码一变即失效，保证不会用到过期产物。
CI 需持久化缓存在 CI 中要显式缓存对应目录，否则每次全新环境都无缓存可命中。
与其他构建优化叠加可与 sharedPrerenderData 等页面生成优化配合，从不同维度共同提速。
零配置即用加入 modules 即可，通常无需额外参数，降低接入成本。

构建缓存解决的是「重复构建」的时间问题，而非「单次冷构建」本身的速度。

如果你的痛点是首次构建太慢，应从依赖精简、transpile 范围、Vite/打包器配置等方向入手；构建缓存更适合作为 CI/CD 与本地高频迭代的「加速补丁」。

同时要注意缓存目录的体积管理，定期清理陈旧缓存，避免磁盘占用无限增长。