在现代前端工程化实践中，构建工具的性能直接影响开发效率。传统的构建工具如 Webpack 在处理大型应用时，往往面临增量更新成本高昂的问题 —— 即使只修改了一行代码，也可能触发整个模块图的重新计算。这种粗粒度的缓存策略源于显式依赖图的维护复杂性，而 Turbopack 通过引入 Value Cell 抽象与自动化细粒度依赖追踪，从根本上改变了这一局面。
从粗粒度缓存到细粒度追踪
传统的构建系统依赖显式声明的依赖图。以 GNU Make 为例，开发者需要在构建规则中手动配置输出目标与前置依赖的对应关系。这种方式虽然在理论上能够实现最优的增量计算，但在实际应用中却暴露出明显的局限性。首先，手动维护依赖图容易出错，尤其当项目规模扩大、模块数量激增时，遗漏或错误的依赖声明会直接导致缓存失效。其次，传统系统无法理解编译器内部的中间表示，只能在文件级别进行粗粒度缓存，无法利用更细粒度的计算结果。
Turbopack 的设计理念是将增量计算的能力下推到函数级别。不同于自顶向下的记忆化方案需要预先声明所有依赖关系，Turbopack 采用了一种「读取时追踪」的机制。每当一个函数读取某个 Value Cell 的值时，系统会自动将该函数及其当前执行上下文记录为该 Cell 的依赖方。这种方式与前端框架中的响应式信号系统有异曲同工之妙，但目标场景从 UI 渲染转移到了编译计算领域。
Value Cell 的核心抽象
Value Cell 在 Turbopack 中以 Vc<T> 的形式存在，代表一个可缓存的计算单元。这个抽象借鉴了电子表格中单元格的隐喻：每个单元格持有某个计算的结果，当其依赖的输入发生变化时，单元格的值会自动失效并在下次读取时重新计算。这种设计使得 Turbopack 能够以极细的粒度组织缓存 —— 一个中间表示、一个模块的 AST、甚至是一个导入导出信息，都可以是独立的 Value Cell。
这种细粒度带来的优势是显著的。假设一个模块导出了一个包含多个函数的对象，在传统记忆化方案中，整个对象被视为一个不可分割的依赖单元，任何一个函数的变化都会导致整个对象的重新计算。而在 Value Cell 体系下，函数级别的变化可以被精确追踪，只有实际被读取的 Cell 才会触发重新计算。这种区分在大型应用中尤为关键，因为应用代码与中间表示之间往往存在复杂的多对多映射关系。
脏值传播与惰性执行机制
当文件系统监控检测到源代码变化时，Turbopack 并不会立即触发大规模重新计算。相反，它首先将变化文件对应的 Value Cell 标记为「脏」状态。接下来，系统会找到所有曾经读取过该 Cell 的函数，将它们加入待处理队列。这一过程会沿着依赖图向上传播：被标记为脏的函数在重新执行时会产生新的中间表示，这些新值又会污染依赖它们的上一层函数。
值得注意的是，Turbopack 采用了惰性执行策略，仅当某个脏函数成为「活跃查询」的一部分时才会真正触发重新计算。在开发模式下，活跃查询对应的是当前正在浏览的页面及其热更新范围；在构建模式下，则是最终产物的完整请求。这种设计避免了不必要的计算开销，使得系统能够在保持快速响应的同时，将计算资源集中在真正需要的结果上。
为了进一步优化传播效率，Turbopack 引入了内容地址特性：当重新计算的中间表示与旧值完全相同时，对应的 Cell 不会被标记为脏值。这避免了无意义的变更向上层传播，确保只有真正产生差异的计算才会触发后续的更新链。
聚合图与大规模查询优化
随着项目规模扩大，依赖图中可能包含数十万甚至数百万个中间结果节点。许多运维操作需要高效查询图中的特定子集，例如收集某个子图的所有错误信息、查找所有受影响的脏节点，或者等待某个范围的计算完成。如果直接遍历细粒度的依赖图，这些操作的性能开销将难以接受。
聚合图是 Turbopack 为解决这一问题而设计的辅助数据结构。它在依赖图的基础上维护了多层摘要节点，每个摘要节点代表原图中一个较大范围的计算单元。底层聚合节点覆盖的范围较小，分辨率较高；随着层级上升，单个节点覆盖的范围逐步扩大，分辨率则相应降低。这种金字塔式的结构使得系统能够以 log 级别的复杂度完成跨大范围的查询操作。
在实际应用中，活跃查询的根节点会与聚合图的特定层级建立映射。当需要收集某个范围的错误信息时，系统只需从对应的聚合节点出发，而非遍历整个依赖图。这种设计使得 Turbopack 能够在保持细粒度缓存优势的同时，不牺牲大规模查询的性能表现。
文件系统缓存与持久化
在 Next.js 16.1 版本中，Turbopack 正式将文件系统缓存作为稳定特性默认启用。在此之前，所有的 Value Cell、依赖图和聚合图都仅存储在内存中，进程重启后需要从头计算。文件系统缓存将这些数据持久化到磁盘，使得开发服务器能够在重启后快速恢复到之前的工作状态。
持久化面临的主要挑战在于数据格式的兼容性与读取效率。Turbopack 团队花费超过一年时间优化这一特性，确保缓存的写入不会成为性能瓶颈，同时读取操作能够在秒级时间内完成。对于大型企业应用而言，这一改进意味着开发者可以在每日工作开始时快速进入状态，而非等待数分钟的冷启动过程。
工程实践中的性能参数
从实际表现来看，Turbopack 的增量编译机制带来了可观的性能提升。在热更新场景下，受影响的模块更新通常能够在约十毫秒内完成，较传统方案快一到两个数量级。这种响应速度使得「编辑即所见」的开发体验成为可能，开发者无需在频繁的等待中打断思路。
构建场景同样受益于细粒度缓存。对于持续迭代的大型项目，增量构建的时间复杂度从与整体代码库规模线性相关，转变为仅与单次变更的影响范围相关。这意味着随着项目逐渐成熟，构建速度并不会自然退化，而是能够维持在相对稳定的水平。
资料来源：Next.js 官方博客「Inside Turbopack: Building Faster by Building Less」。