告别手动注册：D2Admin 的 Vuex 模块自动注册全解-开发者社区

告别手动注册：D2Admin 的 Vuex 模块自动注册全解

【免费下载链接】d2-adminAn elegant dashboard项目地址: https://gitcode.com/gh_mirrors/d2/d2-admin

做 Vue 2 中后台项目时，Vuex 模块数量一旦涨到十几个，你大概率体会过这种痛：入口文件里逐个 import、逐个挂到 modules 上，漏一个就是一片难查的 undefined，入口还越写越长。D2Admin（d2-admin）对这个问题的解法是借助 webpack 的require.context，在 Vuex 状态管理入口处自动扫描模块目录并完成注册——一行代码兜住 15 个业务模块，全程不需要手动维护清单。这篇文章就带你逐段过一遍这套机制的源码，顺带总结可以直接搬回自己项目的套路。

先看效果：一行 require.context 给 Vuex 入口省掉了什么

先看 D2Admin store 的目录分层，一共三层，各管一摊：

src/store/ ├── index.js # 入口：创建 Vuex 实例，注册顶层 d2admin 模块 └── modules/ └── d2admin/ ├── index.js # 聚合器：一行 require.context 收集全部子模块 └── modules/ # 15 个业务模块，全部平铺在这一个目录 ├── account.js ├── theme.js └── ...（其余 13 个 .js 文件）

入口文件 src/store/index.js 只有 5 行有效代码，new Vuex.Store({ modules: { d2admin } })，连具体有哪些子模块都不提。真正的收口在第二层：src/store/modules/d2admin/index.js 用一行require.context把整个 modules 目录扫了一遍。

这套写法带来三个实际收益：

零配置：入口和聚合器都不 import 任何具体模块文件
不遗漏：目录里有文件就一定被注册，不存在"加了文件忘了挂"的情况
扩展只动一处：以后要加报表状态？新建report.js丢进 modules 目录，模块名report自动就位，其余文件一行不用改

文件头注释还特意写了 "There should not be any reason to edit this file"——不应该有任何理由去改这个文件。这句话基本就是这套设计的意图宣言。

自动注册三步走：扫目录、文件名即键名、统一 namespaced 导出

核心逻辑就是十来行代码，拆成三步看。

第一步：扫描目录。

const files = require.context('./modules', false, /\.js$/)

require.context是 webpack 的构建时 API，可以把它理解成一个"限定片区的快递员"：三个参数分别限定投递范围是./modules目录、false表示不递归子目录（所有模块必须平铺在同一层）、正则/\.js$/只收 .js 文件。哪些文件属于这个"片区"在编译阶段就确定了，运行时代价几乎为零。

第二步：文件名即模块名。

const modules = {} files.keys().forEach(key => { modules[key.replace(/(\.\/|\.js)/g, '')] = files(key).default })

files.keys()返回的是一串./theme.js这样的键，正则剥掉./前缀和.js后缀，剩下的部分直接当模块名写进modules对象。也就是说文件叫什么名字，store 里就多了什么模块——约定即配置。

第三步：统一声明命名空间并导出。

export default { namespaced: true, modules }

namespaced是 Vuex 的命名空间开关，作用类似给每个模块套上独立的"包名"，避免不同模块里的 state、action 同名打架。这里由聚合层统一打开，子模块文件里各自也声明一次，两层配合后形成完整的三级隔离。业务模块作者完全不用操心命名空间规则。

15 个业务模块分别在管什么：按角色分组梳理

modules 目录下 15 个文件按职责大致能归成四组，比逐个背名字好理解。

账户与用户组：account负责登录、注销，以及登录成功后的设置批量加载；user.js 只管用户信息的存取，持久化时带user: true参数做用户隔离，不同账号的数据互不串味。

界面状态组：menu管顶栏/侧栏菜单和侧边栏折叠动画，page管多标签页列表与 keep-alive 缓存，fullscreen监听浏览器全屏事件，gray控制全屏灰度（比如注销确认时把背景变灰），search维护全局搜索面板的状态和快捷键。

全局设置组：theme、color、size、transition分别对应主题、主色、组件尺寸、页面过渡动画，这四个也是持久化读写最频繁的一组。

日志与版本组：log记录操作日志，releases在控制台打印版本胶囊信息，ua解析并记录浏览器 UA。

另外还有一个特殊的db模块：它没有 state，只提供 set / get / databasePage 这样一组纯 actions，统一承接所有持久化读写，后面会再讲它的作用。

挑theme模块展开一点看：它的setaction 会先校验主题名在 setting.js 主题列表里存在，然后把值写回 store，接着commit('dom')把theme-xxx这个 class 直接刷到document.body上，最后再异步落到持久化存储——整套 7 套主题的切换就是这三步，见 theme.js L26-L74。下图就是 star 主题生效后的实际背景：

再看account：login action 先调接口拿到凭证，把 uuid 和 token 写进 cookie，再 dispatchd2admin/user/set同步用户信息到 store，最后 await 自己的loadaction。

组件里怎么 dispatch：三级命名空间与同构模式延伸

有了 namespaced 体系，组件里的调用统一是"顶层模块 / 子模块 / 方法"三段式：

// 触发登录 this.$store.dispatch('d2admin/account/login', { username, password }) // 跨模块调用需要 { root: true } this.$store.dispatch('d2admin/db/set', { dbName: 'sys', path: 'theme.activeName', value: 'star', user: true }, { root: true })

这里值得多说一句{ root: true }：模块被命名空间包起来后，dispatch 出来的 action 名默认只在本模块作用域内解析，加上root: true相当于"跳出当前楼层，按根路径寻址"，这样才能从 account 模块里调到 db 模块的 set。

用登录后的加载链路串一遍就很直观：loadaction（account.js L71-L86）会依次 await 七个跨模块 dispatch——user/load、theme/load、transition/load、page/openedLoad、menu/asideLoad、size/load、color/load。每个被调模块的 load 都走同一套路：db/get取值并带 defaultValue 兜底、写回 state、应用到界面。这就是"刷新页面后所有个性化设置原样恢复"的全部秘密，而且七个模块之间互不 import，全靠 db 模块做中转。

这套"扁平目录 + 正则匹配 + 文件名即键名"的套路在 D2Admin 里其实出现了三次，除了 store：

src/assets/svg-icons/index.js：require.context('./icons', false, /\.svg$/)扫 svg 图标，新增一个 svg 文件图标就自动可用
src/i18n.js：require.context('./locales', ...)收集语言包 json，新增语言文件后自动进入切换列表

三处结构完全同构，区别只是正则和目录不同。

最后给几个能直接落地的迁移建议：