当前位置：首页 > news >正文

Vue——别再自己写枚举了！RuoYi-Vue3字典管理全局缓存，让代码量减少90%

news 2026/6/1 10:16:07

1. 核心问题：枚举值管理的痛点

1.1 传统开发中的枚举困境

在后台管理系统中，到处都有枚举值和选项数据：

// ❌ 传统做法：硬编码在各个组件中// 用户状态constuserStatus=[{label:'正常',value:'0'},{label:'停用',value:'1'}];// 性别constsexOptions=[{label:'男',value:'0'},{label:'女',value:'1'},{label:'未知',value:'2'}];// 订单状态constorderStatus=[{label:'待支付',value:'0'},{label:'已支付',value:'1'},{label:'已发货',value:'2'},{label:'已完成',value:'3'}];// 通知类型constnoticeType=[{label:'公告',value:'1'},{label:'通知',value:'2'}];

痛点分析：

⚠️重复定义：每个页面都要重新定义一遍
⚠️不一致：不同地方定义的枚举值可能冲突
⚠️维护困难：修改一个枚举值需要同步多个文件
⚠️无法复用：新增页面需要重新复制粘贴
⚠️后端不匹配：前端枚举值与后端字典数据脱节

1.2 工程级挑战

假设项目有100个下拉框、单选框、复选框： - 每个都需要3-5个选项 - 每个选项需要在3个地方使用（列表展示/搜索表单/编辑表单） - 如果硬编码 → 300次重复定义 - 如果修改一个选项 → 需要同步3个地方 采用字典管理后： - 统一定义在数据库中 → 0次重复 - 修改一个选项 → 自动同步所有地方 - 前端缓存一次加载 → 后续直接使用

2. 解决方案：字典管理的架构设计

2.1 整体架构图

┌─────────────────────────────────────────────────────┐ │ 字典管理系统 │ ├─────────────────────────────────────────────────────┤ │ │ │ 前端层 │ │ ┌──────────────────────────────────────┐ │ │ │ • dict-tag组件（标签渲染） │ │ │ │ • v-dict指令（自动填充） │ │ │ │ • useDict Hook（按需加载） │ │ │ └──────────────────────────────────────┘ │ │ ↓ HTTP请求 │ │ 缓存层（Pinia Store） │ │ ┌──────────────────────────────────────┐ │ │ │ • 字典数据Map存储 │ │ │ │ • 懒加载机制 │ │ │ │ • 缓存失效策略 │ │ │ └──────────────────────────────────────┘ │ │ ↓ RESTful API │ │ 后端层 │ │ ┌──────────────────────────────────────┐ │ │ │ • DictController（字典接口） │ │ │ │ • DictService（业务逻辑） │ │ │ │ • Redis缓存（可选） │ │ │ └──────────────────────────────────────┘ │ │ ↓ SQL查询 │ │ 数据层 │ │ ┌──────────────────────────────────────┐ │ │ │ • sys_dict_type（字典类型表） │ │ │ │ • sys_dict_data（字典数据表） │ │ │ └──────────────────────────────────────┘ │ └─────────────────────────────────────────────────────┘

2.2 数据流转流程

3. 核心实现一：字典数据表设计

3.1 字典类型表

CREATETABLE`sys_dict_type`(`dict_id`bigint(20)NOTNULLAUTO_INCREMENTCOMMENT'字典主键',`dict_name`varchar(100)DEFAULT''COMMENT'字典名称',`dict_type`varchar(100)DEFAULT''COMMENT'字典类型',`status`char(1)DEFAULT'0'COMMENT'状态（0正常 1停用）'