Vuex 模式在 Vue 项目中承担着集中状态管理的职责，但当 store 拆分成多个模块后，构建系统需要处理大量相互依赖的 JavaScript 文件。Webpack 5 的发布为这一场景带来了几个直接可用的改进：文件系统级缓存缩短二次构建时间，模块联邦让多个应用共享 store 成为现实，更细粒度的代码分割能力与 Vuex 的动态注册机制配合得更加自然。这些特性并不要求重写现有状态管理逻辑，而是从构建与分发层面提升效率。
一、Webpack 5 持久化缓存如何加速 Vuex store 构建
Webpack 4 及更早版本在每次构建时都需要重新解析模块、生成依赖图并压缩代码。对于包含大量 Vuex 模块、actions、mutations 的项目来说，即便只修改了一个组件，整个 store 相关文件也会被重新处理。Webpack 5 新增了 cache.type: 'filesystem' 配置，它会把模块构建结果、依赖关系和编译中间产物写入 node_modules/.cache/webpack 目录。第二次构建时，Webpack 会读取这些缓存记录，只对发生变化的文件重新编译，未改动的 Vuex 模块直接复用缓存结果。
这种机制特别适合状态管理代码相对稳定的项目。store 中的 mutation、action 通常不会像 UI 组件那样频繁变动，因此命中缓存的概率很高。根据实际项目规模，二次构建时间通常可以从几十秒下降到几秒甚至更短。配置方式并不复杂，在 webpack.config.js 中加入：
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
config: [__filename]
}
}
};
这里把配置文件本身也加入构建依赖，当 webpack.config.js 变化时缓存会自动失效，避免使用旧配置。需要注意，持久化缓存并不能解决所有问题。如果项目使用了大量动态导入或频繁修改 store 模块，缓存命中率会下降；但它对长期迭代的中大型 Vuex 项目来说收益仍然明显。
二、模块联邦让多应用共享 Vuex store 成为可能
模块联邦是 Webpack 5 引入的跨应用代码共享方案。它允许一个应用在运行时加载另一个应用暴露的模块，而不需要把它们打包成 npm 包或复制代码。对 Vuex 模式而言，最直接的应用场景是微前端架构：主应用需要与子应用共享同一个 store，或者某个子应用负责维护公共状态，其他应用通过联邦远程加载。
例如，一个用户中心应用可以把自己的 Vuex store 暴露出去，主应用在初始化时远程导入并注册。远程应用配置：
// 远程应用 webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'userCenter',
filename: 'remoteEntry.js',
exposes: {
'./store': './src/store'
}
})
]
};
主机应用则在入口文件中动态加载这个远程 store：
// 主机应用 main.js
import('userCenter/store').then(({ default: remoteStore }) => {
const appStore = createStore({
modules: {
user: remoteStore
}
});
app.mount('#app');
});
这种方式的优势在于，子应用可以独立部署、独立迭代状态逻辑，主应用无需重新构建即可获取最新的 store 模块。不过它要求远程 store 的 mutation 和 action 命名不能与主应用冲突，否则在模块名相同的情况下可能出现状态覆盖。建议在模块命名上增加应用前缀，并通过常量表统一管理。
三、Vuex 模块动态注册与按需加载的配合
Vuex 从早期版本就提供了 store.registerModule() 方法，允许在运行期向 store 注入新模块。Webpack 5 对异步 chunk 的拆分更加稳定，支持更细粒度的 splitChunks 配置。两者结合可以实现路由到哪个页面，才加载哪个状态模块的效果，避免首屏加载大量无关状态代码。
假设一个电商项目包含订单、商品、用户三个大模块。如果全部写在入口 store 中，首屏 JavaScript 体积会明显增加。更好的做法是只在根 store 中保留全局状态，路由守卫中按需加载对应模块：
// router.js
router.beforeEach(async (to, from, next) => {
if (to.meta.storeModule && !store.hasModule(to.meta.storeModule)) {
const module = await import(`./store/modules/${to.meta.storeModule}`);
store.registerModule(to.meta.storeModule, module.default);
}
next();
});
上面代码使用动态 import()，Webpack 会为每个 store 模块生成独立的 chunk。只有当用户访问该路由时，浏览器才会请求对应 chunk 并注册到 Vuex。这样既保留了 Vuex 集中式管理的优势，又不会让首屏资源失控。
需要特别留意的是，hasModule 检查可以防止重复注册。如果多次进入同一路由，直接复用已有模块，避免触发 Vuex 的模块覆盖警告。离开路由时也不建议在未确认状态是否仍被其他组件使用时立即 unregisterModule()，否则可能造成状态丢失。
四、避免 tree shaking 与资源模块带来的坑
Webpack 5 在生产模式下默认开启 tree shaking，它会移除没有被引用的导出。Vuex 模块通常以对象形式导出 state、mutations、actions 等属性，如果这些属性在模块内部被引用，一般不会被误删。但如果 store 模块是通过一个聚合文件统一导出，并且聚合文件只导入了部分模块，未使用的模块就可能被 tree shaking 删除，导致运行时报错。
例如下面的聚合写法：
// store/index.js
import user from './modules/user';
import order from './modules/order';
export default createStore({
modules: {
user
// order 未被使用，可能被 tree shaking 删除
}
});
这种情况下 order 模块可能不会被打包。解决方式是在 store 配置中显式保留引用，或确保所有模块都被注册。对于动态注册的场景，动态 import() 本身会产生副作用，Webpack 通常会保留这些模块；但若使用静态导入且仅为了类型提示，建议加上 /* webpackChunkName: "order-store" */ 之类的注释，或者干脆改为动态导入。
此外，Webpack 5 将图片、字体等静态资源默认按模块处理，Vuex 的 state 中如果保存了图片 URL，打包时要注意资源路径。对于需要根据状态切换的图标，建议使用动态导入资源模块，而不是把真实文件路径写死在 store 中。这样状态管理与资源加载可以解耦，也便于缓存和部署。
总的来说，Webpack 5 的新特性并不是直接改变 Vuex 的 API，而是从构建缓存、模块共享、按需加载和资源处理几个方向，让 Vuex 模式在大型项目中的落地更加高效。理解这些能力后，团队可以在不重构状态管理的前提下，获得更好的开发体验与运行性能。