Webpack 5 的发布带来了模块联邦、Asset Modules 和持久化缓存等大量能力，以至于一些偏向开发体验的细节常常被忽略。Twinkling Universe（闪烁宇宙）就是其中之一，它并非 Webpack 官方文档中列出的正式特性，而是社区对依赖图增量更新可视化的一种形象称呼。在 Webpack 5 的 watch 模式或者 webpack-dev-server 下，当你修改一个入口文件时，整个依赖图不会全部重新编译，只有受影响的那一部分模块会更新。如果把这些模块在依赖图中的位置标记出来，就会看到类似夜空中星星依次亮起又熄灭的效果。
这种闪烁的本质是 Webpack 5 对模块状态与缓存键的精细管理。与 Webpack 4 相比，它把 module graph 从 compilation 中独立出来，让依赖关系更清晰。本文会从几个角度展开：先厘清 Twinkling Universe 到底指什么，再分析增量构建如何产生可观测的状态变化，接着给出一个最小插件实现，最后讨论它的性能影响和适用场景。
Twinkling Universe 的概念边界
先说结论：Webpack 官方没有名为 Twinkling Universe 的 API 或配置项。它更像是一个描述性术语，用来指代在增量构建过程中依赖图节点发生高频变化的现象。这个称呼最早出现在一些关于 Webpack 5 构建性能优化的工作坊和博客中，用来形象地表达模块状态切换。由于 Webpack 5 的持久化缓存会把模块的构建结果缓存到磁盘，当文件内容未变化时，模块可以直接从缓存恢复，所以每次 watch 触发的实际工作往往比想象中小得多。
要理解这个概念，可以先回忆 Webpack 4 的 watch 流程。Webpack 4 每次文件变更后，会从入口开始重新解析依赖，虽然也有缓存，但模块状态变化的粒度较粗。Webpack 5 则通过 module graph 和 code generation 缓存，能精确知道哪些模块需要重新构建。Twinkling Universe 就是把这种精确更新映射到二维平面上，让每个模块对应一个点，颜色或亮度随其构建状态变化。于是整个依赖图看起来就像一片会呼吸的星空。
这个特性不是单独的一个开关，而是多个底层机制组合后的表象。它涉及 compilation 对象的 moduleGraph、module 的 buildInfo 与 buildMeta，以及 stats 中暴露的模块级时间数据。开发者如果理解这些数据从何而来，就能自己实现一个轻量的可视化层，而不必依赖特定插件。
增量构建中的模块状态变化
Webpack 5 的一次增量构建大致分为几个阶段：文件监听器触发 invalidate，compiler 创建新的 compilation，然后根据入口和 module graph 判断哪些模块需要重新构建。对于未发生变化的模块，Webpack 会尝试从持久化缓存恢复，这一步甚至不会执行 loader。对于发生变化的模块，它会重新执行 loader、解析依赖、生成代码，并更新 module graph 中对应的节点。
这些模块在构建过程中会经历多种状态。例如一个模块可能先处于 normal 状态，随后进入 build 阶段，再进入 code generation 阶段。Webpack 5 内部并没有公开一个统一的状态机供外部读取，但 compilation.modules 中的每个 module 对象带有 buildInfo 和 buildMeta，同时 compiler.hooks 中提供了丰富的生命周期钩子。我们可以通过监听 compilation.hooks.buildModule、succeedModule、failedModule 等钩子，在模块状态切换时记录时间戳和模块标识。
下面这段代码展示了如何在一个自定义插件中收集模块构建事件，并用简单的终端输出模拟闪烁效果。这里使用了 Webpack 5 的 compilation 钩子，不会修改构建结果，只做观测。
class TwinklingProbePlugin {
apply(compiler) {
compiler.hooks.compilation.tap('TwinklingProbePlugin', (compilation) => {
compilation.hooks.buildModule.tap('TwinklingProbePlugin', (module) => {
const id = module.identifier();
console.log('模块开始构建:', id);
});
compilation.hooks.succeedModule.tap('TwinklingProbePlugin', (module) => {
const id = module.identifier();
console.log('模块完成构建:', id);
});
compilation.hooks.failedModule.tap('TwinklingProbePlugin', (module, error) => {
const id = module.identifier();
console.error('模块构建失败:', id, error.message);
});
});
}
}
module.exports = TwinklingProbePlugin;
这段代码中箭头函数的 => 在 HTML 源码中需要转义为 =>，实际显示为 =>。它的作用是在每次模块开始和完成构建时打印模块标识。如果模块数量很多，终端会快速刷屏，看起来就像星星闪烁。当然这只是最简单的文本版本，真正的可视化还需要把数据发送到浏览器并用 Canvas 或 SVG 绘制。
实现一个最小可视化插件
要把 Twinkling Universe 效果搬到浏览器中，核心思路是建立一个 WebSocket 服务，将模块构建事件实时推送到前端页面。Webpack 的 dev server 本身就带有 WebSocket 用于热更新，但我们这里不依赖它，而是独立创建一个小的 HTTP 和 WebSocket 服务，或者复用现有的开发服务器。
前端页面接收到的每条事件包含模块标识、状态和耗时，然后根据模块在依赖图中的位置计算坐标。依赖图的位置信息可以从 compilation.moduleGraph 中获取，但 moduleGraph 的 API 相对底层，不是所有开发者都熟悉。一种更简单的做法是使用模块标识的哈希值来映射平面坐标，虽然不够精确，但足以形成稳定的星空布局。另一种方式是解析 stats.toJson() 输出的 modules 数组，里面包含 name、issuerName 等信息，可以用 issuerName 建立模块之间的父子关系，再用树形布局计算坐标。
下面给出一个不依赖具体前端框架的插件骨架，它启动一个 WebSocket 服务，并在模块构建事件发生时广播 JSON 消息。为了简单，这里省略了 HTTP 服务器的完整实现，只保留 WebSocket 部分。
const WebSocket = require('ws');
class UniverseServerPlugin {
constructor(options) {
this.options = options || {};
this.wss = null;
}
apply(compiler) {
this.wss = new WebSocket.Server({ port: this.options.port || 9090 });
const broadcast = (data) => {
if (!this.wss) return;
const message = JSON.stringify(data);
this.wss.clients.forEach((client) => {
if (client.readyState === WebSocket.OPEN) {
client.send(message);
}
});
};
compiler.hooks.compilation.tap('UniverseServerPlugin', (compilation) => {
compilation.hooks.succeedModule.tap('UniverseServerPlugin', (module) => {
broadcast({
type: 'module-built',
id: module.identifier(),
timestamp: Date.now()
});
});
});
}
}
module.exports = UniverseServerPlugin;
需要注意的是，这段代码使用了 ws 库，需要预先安装。它只监听 succeedModule 钩子，因此只有当模块成功构建时才广播事件，适合展示正向的闪烁效果。如果还想捕捉缓存命中的模块，可以监听 compilation.hooks.statsFactory 或者直接读取 compilation.modules 的 buildInfo.cacheable 字段，但那样会增加事件量，需要前端做好节流。
前端部分的逻辑通常是：建立 WebSocket 连接，收到消息后在画布上找到对应模块的坐标，改变它的颜色和透明度，然后通过 requestAnimationFrame 逐渐恢复。这样连续多次事件就会形成一种拖尾的闪烁轨迹。为了让效果更接近宇宙星空，可以给每个模块分配随机的初始位置，然后根据依赖关系做简单的力导向布局，但这已经超出 Webpack 本身的范围。
性能影响与使用建议
任何观测行为都会带来额外开销，Twinkling Universe 可视化也不例外。在模块数量较少的项目中，监听构建钩子并通过 WebSocket 发送消息的成本几乎可以忽略。但在包含数千个模块的大型应用中，每个模块构建都触发一次 JSON 序列化和网络发送，可能让增量构建的时间增加几十毫秒甚至更多。因此这类工具应当只在开发环境使用，并且最好加入采样或合并机制，例如每 50 毫秒批量发送一次事件，而不是每个模块都单独发送。
与 Webpack 5 自带的 stats 输出相比，这种可视化更强调实时性和空间位置感。stats 可以提供精确的模块耗时列表，但需要停下来阅读，而 Twinkling Universe 更像一个全局热力图，能让你一眼看出哪些区域的模块被频繁重建。结合持久化缓存命中率，可以快速定位那些因为动态路径、外部变量或错误配置而反复失效的模块。
如果你正在维护一个大型单页应用，建议在开发服务器启动时默认关闭该可视化，仅在需要排查构建性能问题时手动开启。同时把插件设计成可插拔的，通过环境变量控制，避免影响团队其他成员的开发体验。对于生产构建，一定不要启用实时可视化，因为这会破坏 Webpack 5 的并行构建和缓存优化。
最后，Webpack 5 的扩展性让 Twinkling Universe 这类构想成为可能，但它的价值在于帮助理解构建过程，而不是替代常规的优化手段。掌握 moduleGraph 和 compilation 钩子之后，你可以根据自己的项目结构，定制更有针对性的构建反馈工具。
Webpack 5Twinkling Universe闪烁宇宙修改时间：2026-09-22 03:48:02