Vuex模块拆分应按业务闭环而非技术名词划分，每个模块需含完整能力并启用命名空间；支持动态注册/卸载以控制加载与生命周期；配置类状态宜单独归类并只读封装。
拆分 Vuex 模块不是为了“看起来整齐”，而是让状态归属清晰、协作高效、加载可控。核心是按业务闭环划分，而不是按技术名词或页面路径硬切。
按业务功能域而非页面或实体来拆分
比如“用户中心”不应只放 user.profile，而应包含登录态、偏好设置、通知开关、头像上传状态等强耦合项；“营销活动”模块要囊括活动配置、模板管理、发送记录和权限校验逻辑——它们共用同一套时间范围、状态流转和权限规则。避免把 user 和 order 当作两个孤立模块，而要看它们在实际业务中是否被同一组操作驱动、共享同一类副作用（如 token 刷新、错误统一处理）。
每个模块保持完整能力，但默认启用命名空间
每个 modules/xxx.js 文件需导出含 state、mutations、actions、getters 的对象，并显式设置 namespaced: true。这样能防止 action 类型冲突，也便于单元测试和跨项目复用。局部 state 在 mutations 和 getters 中直接可用；需要访问全局状态时，通过 rootState 或 rootGetters 显式声明依赖，不隐藏数据流向。
控制模块加载与生命周期
大型应用中，不是所有模块都需要在首屏加载：
立即学习“前端免费学习笔记（深入）”；
- 路由级模块：配合 Vue Router 的懒加载，在 beforeRouteEnter 或组件 setup 中动态注册（store.registerModule），离开时调用 unregisterModule
- 功能级模块：例如“地图编辑器”只在点击按钮后激活，可封装成函数式 store 初始化，首次调用时才创建实例
- 清理副作用：模块卸载前，清除其内部的定时器、WebSocket 连接、事件监听器；清空缓存型数据（如搜索历史列表），避免内存持续增长
配置类与只读状态单独归类
语言包、主题色、API 基础地址、侧边栏展开状态等轻量高频读取项，适合抽成一个 config 或 setting 模块。这类状态建议：
- 使用 shallowRef 或 readonly 包装，防止意外修改触发重渲染
- 避免与其他业务模块混用 mutations，改用初始化即赋值 + 环境变量或 API 预加载方式注入
- 组件中直接通过 mapState 或 computed 访问，不走 actions
