RuoYi-Vue-Pro 架构总览 | RuoYiPlus

功能列表

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

这是整个平台的「能力地图」。在决定是否使用 RuoYi 之前，你可以通过这个清单快速判断：你需要的能力，这里是否已经内置？如果已经内置，你需要多久能上线？

总代码量约 26 万行，覆盖 19 项系统功能、17 项基础设施、14 个业务子系统。

功能全景

mindmap root((RuoYi-Vue-Pro
功能全景)) 系统功能用户管理角色管理菜单管理部门管理岗位管理租户管理字典管理通知公告操作日志登录日志敏感词管理基础设施代码生成器文件服务消息队列配置管理 WebSocket 服务保障系统监控业务子系统 BPM 工作流 CRM 客户管理 ERP 进销存 Mall 商城 MES 制造执行 WMS 仓库管理 Pay 支付中心 AI 大模型 IoT 物联网 IM 即时通讯

系统功能（19 项）

这些是后台管理的「标配」能力，任何企业系统都需要的通用功能：

功能	解决什么问题	典型场景
用户管理	管理系统登录账号，支持增删改查、重置密码、状态控制	创建员工账号、离职禁用账号
在线用户	实时查看当前在线用户，支持强制下线	安全排查、账号异常处理
角色管理	RBAC 权限模型，角色分配菜单权限和按钮权限	设置「销售经理」只能看 CRM 模块
菜单管理	动态配置左侧菜单，支持目录/菜单/按钮三级	新增业务模块后配置对应菜单
部门管理	组织架构树，支持数据范围权限	北京分公司只能看北京数据
岗位管理	岗位字典，关联用户	关联岗位与薪资/审批权限
租户管理	SaaS 场景的租户注册、套餐分配、过期处理	SaaS 服务商管理多个企业客户
租户套餐	为不同租户套餐绑定不同的菜单权限	基础版/专业版/旗舰版功能差异
字典管理	全局枚举值维护，前后端共用	性别、状态、类型等下拉选项
短信管理	短信模板、发送记录、渠道配置	验证码、通知短信
邮件管理	邮件模板、发送记录、SMTP 配置	注册验证、系统告警
站内信	系统内消息通知，已读/未读状态	审批通知、系统公告
操作日志	记录用户每一次操作，含请求参数和结果	审计追溯、问题排查
登录日志	记录登录 IP、时间、结果	安全审计、异常登录检测
错误码管理	统一错误码定义，前端友好提示	API 返回 `1002005001` 对应「用户不存在」
通知公告	系统级公告发布，支持定时发布	系统维护通知、公司公告
敏感词	敏感词库管理和自动过滤	内容审核、评论过滤
应用管理	多应用配置，如管理后台 + 移动端	一个系统多端入口
地区管理	中国行政区划数据，省市区三级	地址选择器、物流区域

基础设施（17 项）

这些是支撑业务运行的底层能力：

能力	解决什么问题	技术实现
代码生成器	一键生成 CRUD 前后端代码，告别重复劳动	模板引擎，支持主子表、树形表、uni-app
系统接口	基于 Swagger 的在线 API 文档	Swagger3 + Knife4j
数据库文档	自动生成数据库表结构文档	Screw
表单构建	可视化拖拽设计表单	低代码表单设计器
配置管理	动态配置参数，无需重启	系统参数 + 配置中心
文件服务	统一文件上传/下载，多云存储切换	S3 协议：MinIO/阿里云 OSS/腾讯云 COS/七牛云
WebSocket	实时双向通信	单机/集群双模式
API 日志	记录 API 请求和响应详情	拦截器 + 异步写入
MySQL 监控	数据库连接池和慢查询监控	Druid
Redis 监控	Redis 内存、命中率、连接监控	内置监控面板
Java 监控	JVM 内存、线程、GC 监控	Spring Boot Actuator
链路追踪	分布式请求链路跟踪	SkyWalking 集成
日志中心	多服务日志集中查看	日志文件管理
服务保障	分布式锁、幂等性、限流、防重	Redisson + 自定义注解
单元测试	保障代码质量	JUnit5 + 1121+ 测试用例

业务子系统总览

子系统	表数量	一句话描述
BPM 工作流	-	审批流程引擎，仿钉钉设计器
Pay 支付中心	-	统一支付/退款/转账，屏蔽渠道差异
Report 报表	-	拖拽式大屏设计，三种报表引擎
Member 会员	-	会员体系，VIP 等级，积分签到
MP 公众号	-	多公众号管理，粉丝消息自动回复
Mall 商城	70+	完整 B2C 电商系统
CRM 客户管理	20+	线索→商机→合同→回款全流程
ERP 进销存	30+	采购/销售/库存/财务一体化
Sale 销售财务	-	ERP 子模块，收款/付款/结算
WMS 仓库管理	16	通用仓储管理
MES 制造执行	133	车间级生产制造管理
AI 大模型	-	对话/绘画/知识库/工作流
IoT 物联网	-	设备管理/物模型/规则引擎
IM 即时通讯	16	私聊/群聊/频道/音视频

适合什么样的用户

Java 开发者：有 Spring Boot 基础，想快速交付企业级项目
中小型团队：需要一套覆盖多业务场景的底座，减少重复开发
企业 IT 部门：内部信息化建设，需要审批流、进销存、CRM 等成熟模块
SaaS 服务商：需要多租户能力和模块化架构来服务多个客户

Report 报表与大屏

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

Report 模块让非技术人员也能做出专业的数据大屏。不需要写前端代码，通过拖拽组件、配置数据源，就能生成可视化报表和大屏页面。适合管理层看板、数据监控、项目汇报等场景。

一句话：像做 PPT 一样做数据大屏。

解决什么问题

痛点	Report 如何解决
管理层想看数据，每次都让开发写页面	拖拽式设计，业务人员自己做
数据展示需求频繁变化	修改大屏配置即可，无需发版
需要专业的可视化效果	内置几十种图表组件和模板
不同场景需要不同的报表引擎	提供三种引擎，按需选择

用户角色

graph LR subgraph 角色 DESIGNER["大屏设计师
拖拽配置大屏
设置数据源
发布大屏"] VIEWER["查看者（管理层/客户）
查看大屏
交互筛选数据"] end

三种报表引擎

graph TB subgraph GoView["Go-View（推荐）"] G1["开源免费"] G2["Vue3 技术栈"] G3["纯前端，独立部署"] G4["内置丰富图表组件"] end subgraph Jimu["JimuReport"] J1["不开源"] J2["内嵌后端"] J3["支持复杂报表"] J4["中国式报表"] end subgraph AJ["AJ-Report"] A1["开源"] A2["开发中"] A3["完全后端驱动"] end

特性	Go-View	JimuReport	AJ-Report
开源	✅	❌	✅
上手难度	⭐ 低	⭐⭐ 中	⭐⭐ 中
图表丰富度	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
复杂报表	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
推荐场景	通用大屏	中国式复杂报表	后端驱动场景

大屏设计流程

flowchart LR A["新建大屏
选择模板或空白"] --> B["拖拽组件
图表/文本/图片/边框"] B --> C["配置数据源
API 接口 / 静态数据"] C --> D["调整样式
布局/颜色/动画"] D --> E["预览效果
实时查看"] E --> F{满意?} F -->|是| G["发布大屏
生成访问链接"] F -->|否| B

内置图表组件（部分）

折线图 / 柱状图 / 饼图 / 雷达图
数据表格 / 滚动表格
数字翻牌器
地图（中国 / 省市）
仪表盘
词云
时间轴
边框和装饰组件

典型应用场景

场景	大屏内容	查看者
销售看板	今日销售额、订单量、转化率、区域排名	销售总监、管理层
生产监控	产线状态、产量、不良率、设备 OEE	生产经理、厂长
运营大屏	用户增长、活跃度、留存率、收入趋势	运营团队
项目汇报	项目进度、里程碑、风险、资源使用	项目干系人

AI 大模型

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

AI 模块是一站式 AI 能力集成平台，对接国内外主流大模型，提供对话、绘画、知识库（RAG）、工具调用、工作流、写作、思维导图、音乐创作等 8 大 AI 能力。无论是想给系统加一个 AI 助手，还是想做 AI 原生应用，这里都有现成的能力。

一句话：让你的系统「会聊天、会画画、会写文章、会唱歌」。

解决什么问题

痛点	AI 模块如何解决
接入大模型需要逐个对接 API	统一对接国内外主流模型，一次集成
企业内部知识无法被 AI 利用	RAG 知识库，让 AI 读懂你的文档
AI 能力单一（只会聊天）	8 大能力模块覆盖多种场景
需要编排 AI 工作流	集成 Dify/FastGPT/Coze 工作流平台
国内模型和国外模型切换复杂	统一 API 层，切换模型无需改代码

用户角色

graph LR subgraph 角色 AI_ADMIN["AI 管理员
配置模型接入
管理知识库
设置权限"] AI_USER["AI 使用者
对话聊天
绘画创作
知识库问答
写作/思维导图"] AI_DEV["开发者
通过 API 集成 AI 能力
创建自定义工作流"] end

8 大功能模块

graph TB AI_CORE["AI 大模型平台"] AI_CORE --> CHAT["💬 AI 对话
多模型聊天
上下文记忆
联网搜索
推理模式 Thinking"] AI_CORE --> IMAGE["🎨 AI 绘画
文生图
支持 Stable Diffusion
Midjourney"] AI_CORE --> RAG["📚 AI 知识库
RAG 检索增强生成
上传文档即问答"] AI_CORE --> TOOL["🔧 AI 工具调用
Function Calling
MCP 协议"] AI_CORE --> WORKFLOW["🔄 AI 工作流
集成 Dify/FastGPT/Coze
可视化编排"] AI_CORE --> WRITE["✍️ AI 写作
文章/报告/邮件
多场景模板"] AI_CORE --> MINDMAP["🧠 AI 思维导图
自动生成脑图"] AI_CORE --> MUSIC["🎵 AI 音乐
Suno AI 音乐创作"]

支持的模型

国内模型

模型	提供方	特点
通义千问	阿里云	综合能力强
DeepSeek	深度求索	性价比高，推理能力强
豆包	字节跳动	多模态能力
混元	腾讯	生态集成好
文心一言	百度	中文理解强
GLM	智谱 AI	开源友好
星火	科大讯飞	语音能力突出
Moonshot	月之暗面	长上下文
MiniMax	MiniMax	多模态
BaiChuan	百川智能	中文优化
SiliconFlow	SiliconFlow	多模型聚合

国外模型

模型	提供方
GPT	OpenAI
Claude	Anthropic
Llama	Meta
Gemini	Google

核心能力详解

AI 对话

用户：帮我分析一下这个季度的销售数据
 ↓
AI：根据数据，Q3 销售额同比增长 15%，其中...
 ↓ （支持 Thinking 推理模式）
展示完整推理过程 + 结论

支持联网搜索，让 AI 获取实时信息。

AI 知识库（RAG）

flowchart LR DOC["上传文档
PDF/Word/网页"] --> PARSE["文档解析
分段/向量化"] PARSE --> STORE["向量存储"] QUERY["用户提问"] --> SEARCH["检索相关段落"] STORE --> SEARCH SEARCH --> LLM["大模型
结合上下文回答"] LLM --> ANSWER["精准回答"]

AI 工作流

集成 Dify、FastGPT、Coze 等平台，可以可视化编排复杂的 AI 工作流，如：

智能客服：用户问题 → 意图识别 → 知识库检索 → 转人工判断
内容生成：关键词 → 大纲 → 正文 → 配图 → 发布

CRM 客户关系管理

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

CRM 是销售团队的「作战指挥系统」。从一条线索开始，到转化为客户、创建商机、签订合同、收到回款——整个销售漏斗在这里全程可视化。配合公海机制，防止客户资源被个别销售「私藏」。

一句话：让你的销售团队告别 Excel 管客户，让每一笔生意都有迹可循。

解决什么问题

痛点	CRM 如何解决
客户信息散落在销售个人微信/Excel 里	统一客户库，离职交接不丢数据
销售撞单，多人跟进同一客户	客户锁定机制 + 公海规则
不知道销售每天在干什么	跟进记录、拜访记录全程留痕
不清楚销售漏斗哪个环节有问题	线索→客户→商机→合同转化率可视化
回款管理混乱	合同 → 回款计划 → 回款记录全链路

用户角色

graph LR subgraph 角色 SALES["销售人员
跟进线索和客户
创建商机和合同
记录跟进和回款"] MANAGER["销售经理
分配线索和客户
审批合同
查看团队数据"] ADMIN4["管理员
配置公海规则
管理产品目录
数据统计分析"] end

销售全流程

flowchart LR A["🔍 线索
潜在客户来源"] -->|转化| B["👤 客户
正式客户"] B -->|创建| C["💼 商机
销售机会"] C -->|推进| D["📝 合同
签约"] D -->|收款| E["💰 回款
资金到账"] A -.->|无效| X1["❌ 无效线索"] B -.->|长期未跟进| X2["🌊 掉入公海"] X2 -.->|被其他销售领取| B C -.->|输单| X3["❌ 关闭商机"]

核心表结构（ER 图）

erDiagram CRM_CLUE ||--o| CRM_CUSTOMER : "转化为" CRM_CUSTOMER ||--o{ CRM_CONTACT : "拥有" CRM_CUSTOMER ||--o{ CRM_BUSINESS : "创建" CRM_BUSINESS ||--o{ CRM_CONTRACT : "推进为" CRM_CONTRACT ||--o{ CRM_RECEIVABLE : "回款" CRM_CONTRACT ||--o{ CRM_RECEIVABLE_PLAN : "回款计划" CRM_CLUE { bigint id PK varchar name "线索名称" varchar mobile "手机号" tinyint status "状态" bigint owner_user_id FK "负责人" } CRM_CUSTOMER { bigint id PK varchar name "客户名称" tinyint level "客户等级" bigint owner_user_id FK "负责人" } CRM_CONTACT { bigint id PK bigint customer_id FK varchar name "联系人姓名" varchar mobile "手机号" } CRM_BUSINESS { bigint id PK bigint customer_id FK varchar name "商机名称" decimal total_price "预计金额" tinyint status "阶段" } CRM_CONTRACT { bigint id PK bigint business_id FK varchar no "合同编号" decimal total_price "合同金额" tinyint status "状态" } CRM_RECEIVABLE { bigint id PK bigint contract_id FK decimal price "回款金额" datetime time "回款时间" }

公海机制

规则	说明
自动释放	超过 N 天未跟进，客户自动掉入公海
提前提醒	到期前提醒销售及时跟进
锁定保护	成交客户永久锁定，不会掉入公海
客户上限	每个销售有最大客户数限制，防止囤积
定时任务	后台定时扫描并执行公海释放逻辑

数据权限

CRM 采用负责人机制实现数据隔离：

每个客户/线索/商机/合同都有 owner_user_id 字段
销售只能看到自己的数据
销售经理可以看到团队数据
管理员可以看到全部数据
支持转移操作：将客户转移给其他销售

功能清单

模块	功能
线索管理	线索录入、分配、转化、无效标记
客户管理	客户信息、联系人、跟进记录、锁定
公海客户	公海池、领取、释放规则
商机管理	商机阶段、预计金额、输赢单
合同管理	合同创建、审批、变更
回款管理	回款计划、回款记录、应收统计
产品管理	产品目录、价格
数据统计	漏斗分析、业绩统计

Member 会员中心

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

Member 模块提供独立的会员用户体系，与后台管理员用户（system_users）完全隔离。它是商城系统的用户基础，负责会员注册、登录、等级成长、积分运营等 C 端用户全生命周期管理。

关键区分：管理员登录后台用的是 system_users（系统用户），C 端用户注册登录用的是 member_user（会员用户），两套体系完全独立。

解决什么问题

痛点	Member 如何解决
C 端用户需要独立的注册登录	独立的会员用户表，不与管理后台用户混淆
需要会员等级和权益体系	VIP 等级 + 成长值机制
需要提升用户活跃和留存	积分签到、积分商城
微信生态用户需要一键登录	公众号登录、小程序登录、小程序订阅消息

用户角色

graph LR subgraph 后台角色 ADMIN3["运营人员
管理会员信息
配置 VIP 等级
管理积分规则
设置会员标签和分组"] end subgraph C端角色 MEMBER2["普通会员
注册/登录/个人信息"] VIP["VIP 会员
享受等级权益
积分获取和使用"] end

会员体系架构

graph TB subgraph 账号体系 LOGIN["登录方式
手机号/邮箱/微信"] REGISTER["注册
手机号/微信授权"] end subgraph 等级体系 LEVEL["VIP 等级
普通 → 银卡 → 金卡 → 钻石"] GROWTH["成长值
消费/签到/任务获取"] LEVEL --> GROWTH end subgraph 积分体系 POINTS_GET["积分获取
签到/消费/活动"] POINTS_USE["积分使用
抵扣/兑换"] POINTS_GET --> POINTS_USE end subgraph 运营体系 TAG["会员标签
画像标记"] GROUP["会员分组
精准运营"] end LOGIN --> 会员用户表 REGISTER --> 会员用户表会员用户表 --> 等级体系会员用户表 --> 积分体系会员用户表 --> 运营体系

微信生态集成

graph TB MEMBER3["会员模块"] subgraph 微信能力 MP_LOGIN["公众号登录
微信内 H5 授权"] MINI_LOGIN["小程序登录
一键获取手机号"] MINI_QR["小程序二维码
带参数二维码"] MINI_MSG["小程序订阅消息
订单/物流/活动通知"] end MEMBER3 --> MP_LOGIN MEMBER3 --> MINI_LOGIN MEMBER3 --> MINI_QR MEMBER3 --> MINI_MSG

与商城的关系

graph LR MEMBER4["Member 会员中心
提供：会员信息/等级/积分"] --> MALL2["Mall 商城
消费：使用会员身份下单
获取：下单获得积分和成长值"] MALL2 --> MEMBER4

商城依赖会员模块提供用户身份，同时商城的消费行为会反哺会员的积分和成长值。

核心功能清单

功能	说明
会员管理	会员列表、详情、状态管理
会员标签	自定义标签，用户画像标记
会员等级	VIP 等级配置、成长值规则、升降级
会员分组	按条件分组，支持精准推送
积分签到	签到规则配置、连续签到奖励
积分记录	积分明细、流水追溯

MP 微信公众号

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

MP 模块是微信公众号的「多账号管理中心」。如果你运营着多个公众号，不需要登录微信公众平台一个个切换——在这里可以集中管理所有公众号的粉丝、消息、菜单、素材和自动回复。

一句话：一个后台管理所有公众号，运营效率翻倍。

解决什么问题

痛点	MP 如何解决
多个公众号切换管理繁琐	一个后台管理多个公众号
粉丝信息分散	统一粉丝列表、标签管理
自动回复规则配置复杂	可视化配置关注回复、消息回复、关键字回复
菜单配置体验差	可视化菜单编辑器，实时预览
无法与业务系统联动	粉丝数据与会员模块打通

用户角色

graph LR subgraph 角色 OP["公众号运营
管理粉丝和消息
配置自动回复
编辑菜单
管理素材
查看数据统计"] FAN["粉丝
关注公众号
发送消息
触发自动回复"] end

功能架构

graph TB subgraph 核心功能["10 大功能模块"] ACCOUNT["账号管理
绑定多个公众号"] STATS["数据统计
粉丝增长/消息统计"] FANS["粉丝管理
粉丝列表/标签/同步"] MSG["消息管理
接收/回复消息"] AUTO["自动回复
关注/消息/关键字"] TEMPLATE["模板消息
业务通知推送"] TAG2["标签管理
粉丝分组"] MENU["菜单管理
可视化配置"] MATERIAL["素材管理
图文/图片/音频"] DRAFT["图文草稿箱"] end subgraph 微信API["微信公众号 API"] WX_API["消息接收/发送
菜单推送
素材上传
用户信息获取"] end 核心功能 --> 微信API

自动回复规则

flowchart LR EVENT["用户行为"] --> TYPE{回复类型} TYPE -->|关注公众号| FOLLOW["关注回复
欢迎语 + 引导"] TYPE -->|发送消息| KEYWORD{匹配关键字?} KEYWORD -->|完全匹配| EXACT["关键字回复"] KEYWORD -->|模糊匹配| LIKE["模糊匹配回复"] KEYWORD -->|无匹配| DEFAULT["默认消息回复"]

与业务系统的联动

公众号粉丝可以同步为会员用户，商城可以通过模板消息向用户推送订单状态，形成完整的微信生态闭环。

核心功能清单

功能	说明
账号管理	绑定多个公众号，切换管理
数据统计	粉丝增长趋势、消息互动统计
粉丝管理	粉丝列表、详情、标签、黑名单
消息管理	接收粉丝消息、人工回复
自动回复	关注回复、默认回复、关键字回复
模板消息	向粉丝推送模板消息
标签管理	粉丝分组标签
菜单管理	可视化底部菜单配置
素材管理	图文、图片、语音、视频素材库
图文草稿箱	图文消息草稿编辑

Mall 商城系统

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

Mall 商城是平台最复杂的业务模块（70+ 张表），提供从商品管理、订单交易到营销活动、分销佣金的全链路电商能力。一套系统同时拥有管理后台（Vue3+Element Plus）和移动端（uni-app），开箱即用。

一句话：如果你需要做一个 B2C 商城，这里已经实现了 90% 的功能。

解决什么问题

痛点	Mall 如何解决
从零开发商城周期长	70+ 张表 + 完整前后端，几周上线
多种营销玩法开发成本高	内置优惠券/秒杀/拼团/砍价/分销
需要管理端+用户端两套前端	管理后台 + uni-app 移动端一起提供
支付和会员需要额外对接	内置对接支付中心和会员中心

用户角色

graph LR subgraph 后台角色 MALL_ADMIN["商城管理员
管理商品/订单/营销"] MALL_OP["运营人员
配置活动/审核评价"] end subgraph C端角色 BUYER["买家
浏览商品/下单/支付
参与营销活动"] DISTRIBUTOR["分销员
推广商品
获取佣金"] end

系统架构

graph TB subgraph 管理后台 ADMIN_PANEL["Vue3 + Element Plus 管理后台
商品/订单/营销/数据"] end subgraph 移动端 UNI_APP["uni-app 移动端
H5 + APP + 小程序
店铺装修（3套模板）"] end subgraph 商品中心 CATEGORY["商品分类"] ATTR["商品属性"] SPU["SPU 商品"] SKU["SKU 规格"] REVIEW["商品评价"] end subgraph 订单中心 CART["购物车"] ORDER["交易订单"] AFTER_SALE["售后管理"] EXPRESS["快递发货"] PICKUP["自提核销"] end subgraph 营销中心 COUPON["优惠券"] SECKILL["秒杀活动"] BARGAIN["砍价活动"] GROUPON["拼团活动"] DISCOUNT["限时折扣"] CONTENT["内容营销"] COMMISSION["分销佣金"] end subgraph 依赖模块 PAY2["支付中心"] MEMBER6["会员中心"] MP3["公众号"] end 管理后台 --> 商品中心管理后台 --> 订单中心管理后台 --> 营销中心移动端 --> 商品中心移动端 --> 订单中心移动端 --> 营销中心订单中心 --> PAY2 订单中心 --> MEMBER6 营销中心 --> MEMBER6

核心业务流程

用户下单流程

sequenceDiagram participant U2 as 用户 participant APP as 移动端/PC participant MALL4 as 商城 participant PAY3 as 支付中心 participant WMS2 as 仓库/WMS U2->>APP: 浏览商品，加入购物车 U2->>APP: 确认订单，选择地址 APP->>MALL4: 创建订单（待支付） MALL4->>PAY3: 发起支付 PAY3-->>APP: 支付页面 U2->>PAY3: 完成支付 PAY3->>MALL4: 回调：支付成功 MALL4->>MALL4: 订单状态 → 待发货 MALL4->>WMS2: 通知发货 WMS2->>MALL4: 录入快递单号 MALL4->>APP: 推送发货通知 U2->>APP: 确认收货 MALL4->>MALL4: 订单完成，发放积分

营销活动矩阵

活动类型	玩法	适合场景
优惠券	满减/折扣/代金券，可指定商品/分类	日常促销
秒杀	限时限量，超低价抢购	引流、清库存
拼团	多人拼团享优惠价	社交裂变
砍价	分享好友帮忙砍价	拉新获客
限时折扣	指定时间段打折	节日促销
内容营销	图文/视频种草	内容电商
分销佣金	推广分佣，多级分销	社交电商

店铺装修

移动端支持 3 套店铺装修模板，可通过拖拽组件自定义首页布局：

轮播图 / 导航图标 / 商品推荐
优惠券弹窗 / 倒计时
搜索栏 / 公告栏

依赖关系

Mall 商城
 ├── 支付中心（Pay） —— 订单支付
 ├── 会员中心（Member） —— 用户身份/积分
 └── 公众号（MP） —— 微信内 H5 商城

ERP 企业资源计划

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

ERP 是企业的「进销存中枢」——管理从供应商采购、仓库库存到客户销售的完整实物和资金流动。30+ 张表覆盖采购、销售、库存、产品、财务五大核心，适合商贸企业和制造企业的日常运营管理。

一句话：管好你的货和钱，让每一笔进出都有据可查。

解决什么问题

痛点	ERP 如何解决
库存数量靠人工盘点，经常对不上	每笔出入库自动更新库存，实时准确
采购和销售流程不透明	单据审批流 + 状态追踪
不清楚赚了多少钱	采购成本 vs 销售收入，自动核算
多仓库调拨混乱	移库操作有记录，库存位置清晰
财务收款付款难管理	结算账户 + 收付款记录

用户角色

graph LR subgraph 角色 PURCHASER["采购员
管理供应商
创建采购订单
处理采购入库和退货"] SALES2["销售员
管理客户
创建销售订单
处理销售出库和退货"] WAREHOUSE["仓管员
确认入库/出库
管理库存
执行盘点"] FINANCE["财务
管理结算账户
处理收付款
审核单据"] MANAGER2["管理者
审批单据
查看报表"] end

五大核心模块

采购流程

sequenceDiagram participant P as 采购员 participant ERP3 as ERP participant S as 供应商 participant WH as 仓库 P->>ERP3: 选择供应商，创建采购订单 ERP3->>ERP3: 订单状态：待审批 Note over ERP3: 可集成 BPM 工作流审批 ERP3->>ERP3: 审批通过 P->>S: 通知供应商发货 S->>WH: 货物送达 WH->>ERP3: 创建采购入库单 ERP3->>ERP3: 入库审批通过 ERP3->>ERP3: 库存增加 Note over ERP3: 若需退货 P->>ERP3: 创建采购退货单 ERP3->>ERP3: 退货审批通过 → 库存减少

销售流程

sequenceDiagram participant C as 客户 participant S2 as 销售员 participant ERP4 as ERP participant WH2 as 仓库 C->>S2: 下达采购需求 S2->>ERP4: 创建销售订单 ERP4->>ERP4: 订单审批通过 S2->>WH2: 通知仓库备货 WH2->>ERP4: 创建销售出库单 ERP4->>ERP4: 出库审批通过 ERP4->>ERP4: 库存减少 WH2->>C: 发货 Note over ERP4: 若需退货 S2->>ERP4: 创建销售退货单 ERP4->>ERP4: 退货审批通过 → 库存增加

核心表结构

erDiagram ERP_PRODUCT ||--o{ ERP_PURCHASE_ORDER_ITEM : "采购" ERP_PRODUCT ||--o{ ERP_SALE_ORDER_ITEM : "销售" ERP_PRODUCT ||--o{ ERP_STOCK : "库存" ERP_PURCHASE_ORDER ||--o{ ERP_PURCHASE_ORDER_ITEM : "包含" ERP_PURCHASE_ORDER ||--o{ ERP_PURCHASE_IN : "入库" ERP_SALE_ORDER ||--o{ ERP_SALE_ORDER_ITEM : "包含" ERP_SALE_ORDER ||--o{ ERP_SALE_OUT : "出库" ERP_STOCK { bigint id PK bigint product_id FK "产品" bigint warehouse_id FK "仓库" int stock "库存数量" } ERP_PURCHASE_ORDER { bigint id PK varchar no "单据编号" bigint supplier_id FK "供应商" tinyint status "状态" decimal total_price "总金额" } ERP_SALE_ORDER { bigint id PK varchar no "单据编号" bigint customer_id FK "客户" tinyint status "状态" decimal total_price "总金额" }

单据编号规则

格式：{prefix}{yyyyMMdd}{6位自增}
示例：CGD20240625000001（采购订单）
 XSD20240625000001（销售订单）

审批机制

所有出入库单据都有审批状态（ErpAuditStatus）：

状态	说明
未审批	草稿状态，可编辑
已审批	审批通过，触发库存变更

关键规则：审批通过后才影响库存，审批驳回的单据不产生库存变动。

依赖关系

ERP 进销存
 └── BPM 工作流（可选）—— 审批流程

WMS 仓库管理系统

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

WMS 是独立的通用仓库管理系统（16 张表），与 MES 中深度集成制造的仓库模块是两套系统。WMS 定位为「通用仓储管理」，适合纯仓储场景；如果你需要深度集成制造（如线边库、生产领料），请使用 MES 中的仓库模块。

一句话：管好仓库的「进、出、移、盘」，让每一件货都知道在哪里。

解决什么问题

痛点	WMS 如何解决
仓库有多少货不知道	实时库存查询，库存流水追溯
出入库记录靠纸质单据	电子单据，状态流转可追踪
货物位置不清楚	多仓库、库位管理
盘点耗时耗力	系统化盘点流程
库存数据不准	每笔操作自动更新库存

用户角色

graph LR subgraph 角色 WH_ADMIN["仓库管理员
管理仓库/库位
配置商品信息
处理入库/出库/移库/盘点
查看库存"] end

核心业务流程

graph TB subgraph 入库流程 IN1["创建入库单"] --> IN2["草稿状态"] IN2 --> IN3["确认完成"] IN3 --> IN4["库存增加"] IN2 --> IN5["作废"] end subgraph 出库流程 OUT1["创建出库单"] --> OUT2["草稿状态"] OUT2 --> OUT3["确认完成"] OUT3 --> OUT4["库存减少"] OUT2 --> OUT5["作废"] end subgraph 移库流程 MV1["创建移库单"] --> MV2["确认完成"] MV2 --> MV3["源仓库库存减少
目标仓库库存增加"] end subgraph 盘点流程 CK1["创建盘点单"] --> CK2["录入实盘数量"] CK2 --> CK3["确认完成"] CK3 --> CK4["盘盈：库存增加
盘亏：库存减少"] end

核心表结构

erDiagram WMS_WAREHOUSE ||--o{ WMS_STOCK : "库存" WMS_PRODUCT ||--o{ WMS_STOCK : "库存" WMS_WAREHOUSE { bigint id PK varchar name "仓库名称" varchar code "仓库编码" tinyint status "状态" } WMS_PRODUCT { bigint id PK varchar name "商品名称" varchar no "商品编码" varchar unit "单位" } WMS_STOCK { bigint id PK bigint warehouse_id FK "仓库" bigint product_id FK "商品" int stock "库存数量" } WMS_STOCK_RECORD { bigint id PK bigint warehouse_id FK bigint product_id FK int count "变动数量" tinyint type "出入类型" varchar business_no "关联单据号" }

单据编号规则

格式：{prefix}{月日}{4位随机数}
示例：RK06250001（入库单）
 CK06250001（出库单）
 YK06250001（移库单）
 PK06250001（盘点单）

两阶段状态流转

所有单据遵循草稿 → 完成/作废的两阶段模式：

状态	说明
草稿	可编辑，不触发库存变更
已完成	确认完成，触发库存事务
已作废	单据作废，不触发库存变更

关键规则：只有「已完成」状态才会真正影响库存数量。

与 MES 仓库的区别

维度	WMS	MES 仓库模块
定位	通用仓储管理	制造深度集成
表数量	16 表	62 表
适用场景	独立仓储、物流中心	制造工厂、生产车间
特色功能	基础出入库盘点	线边库、生产领料、外协管理
是否需要 MES	❌ 独立使用	✅ 属于 MES 的一部分

MES 制造执行系统

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

MES 是整个平台中规模最大的业务模块（133 张表），面向制造企业的车间级管理需求。它不只是「进销存」，而是深入到生产工单、工艺路线、排产调度、报工记录、质量检验、设备维护的完整制造执行体系。

一句话：如果你的工厂需要管「工单怎么排、工序怎么做、质量怎么检、设备怎么修」，MES 就是答案。

解决什么问题

痛点	MES 如何解决
生产进度不透明	工单 → 排产 → 报工全链路追踪
质量检验靠纸质记录	IQC/IPQC/OQC/RQC 电子化
设备故障影响交期	设备台账 + 点检计划预防性维护
物料管理混乱	线边库 + 生产领料/退料管理
外协加工难以管理	外协出入库独立管理
工人排班复杂	排班管理模块

用户角色

graph LR subgraph 角色 PLANNER["计划员
创建生产工单
制定排产计划"] WORKER["操作工
查看工单任务
报工记录
领料/退料"] QC["质检员
IQC 来料检验
IPQC 过程检验
OQC 出货检验"] MAINTENANCE["设备维护员
设备台账管理
执行点检计划"] SUPERVISOR["车间主任
查看生产进度
安灯异常处理"] end

七大模块全景

graph TB subgraph MD["基础数据 md（17 表）"] MD1["物料/产品"] MD2["客商管理"] MD3["车间管理"] MD4["编码规则"] end subgraph PRO["生产管理 pro（17 表）"] PRO1["工艺路线"] PRO2["生产工单"] PRO3["排产单"] PRO4["报工记录"] PRO5["安灯系统"] end subgraph WM["仓库管理 wm（62 表）"] WM1["库位设置"] WM2["库存管理"] WM3["采购入库"] WM4["成品入库"] WM5["销售出库"] WM6["领料退料"] WM7["移库管理"] WM8["盘点管理"] WM9["杂项出入库"] WM10["外协管理"] end subgraph QC2["质量管理 qc（16 表）"] QC1["IQC 来料检验"] QC2_IN["IPQC 过程检验"] QC3["OQC 出货检验"] QC4["RQC 退货检验"] end subgraph DV["设备管理 dv（12 表）"] DV1["设备台账"] DV2["点检计划"] DV3["点检记录"] end subgraph TM["工具管理 tm（2 表）"] TM1["工具台账"] TM2["工具领用"] end subgraph CAL["排班管理 cal（7 表）"] CAL1["班次定义"] CAL2["排班计划"] end MD --> PRO MD --> WM PRO --> WM PRO --> QC2

生产执行流程

sequenceDiagram participant PLAN as 计划员 participant MES2 as MES participant LINE as 产线 participant QC3 as 质检员 participant WH3 as 仓库 PLAN->>MES2: 创建生产工单 PLAN->>MES2: 制定排产计划 MES2->>LINE: 工单下发到产线 LINE->>WH3: 领料申请 WH3->>MES2: 确认发料 LINE->>MES2: 工序报工 QC3->>MES2: IPQC 过程检验 LINE->>MES2: 完工报工 QC3->>MES2: OQC 出货检验 LINE->>WH3: 成品入库

质量检验体系

graph LR subgraph IQC["IQC 来料检验"] I1["供应商来料"] I2["检验 → 合格/不合格"] I3["不合格 → 退货/让步接收"] end subgraph IPQC["IPQC 过程检验"] P1["生产过程中抽检"] P2["关键工序检验"] P3["异常处理"] end subgraph OQC["OQC 出货检验"] O1["成品出货前检验"] O2["合格 → 放行"] end subgraph RQC["RQC 退货检验"] R1["客户退货检验"] R2["判定责任归属"] end IQC --> IPQC --> OQC RQC -.-> IQC

虚拟线边库（WIP）

MES 仓库模块中有一个特殊概念——虚拟线边库（WIP_VIRTUAL_WAREHOUSE），用于统计车间在制物资：

物料从仓库发到产线 → 线边库增加
产线消耗物料 → 线边库减少
成品完工 → 线边库减少，成品库增加

这让车间在制品的数量和位置始终清晰。

与其他模块的关系

关系	说明
MES vs WMS	WMS 是通用仓库管理，MES 的仓库模块深度集成制造（线边库、领料、外协）
MES vs ERP	ERP 管「进销存」，MES 管「生产执行」，互补关系
MES vs IoT	IoT 可用于设备数据采集，MES 用于生产管理
MES vs BPM	可集成 BPM 做质检异常审批等

销售与财务管理

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

这是 ERP 系统的财务子模块，由 yudao-module-erp 的 finance 包实现。它不独立存在，而是紧密集成在 ERP 的采购和销售流程中，负责资金流的记录和管理。

一句话：采购了要付款，销售了要收款，退货了要退款——财务模块就是管这些「钱」的事情。

解决什么问题

痛点	财务模块如何解决
不知道哪个供应商欠了多少钱	结算账户余额清晰可见
付款后无法关联到具体采购单	付款单关联采购入库单
收款和销售订单脱节	收款单关联销售出库单
退款流程混乱	退货单自动触发退款流程

用户角色

graph LR subgraph 角色 FINANCE2["财务人员
管理结算账户
处理付款/收款
处理退款
核对账目"] end

核心 ER 图

erDiagram ERP_ACCOUNT ||--o{ ERP_FINANCE_PAYMENT : "付款" ERP_ACCOUNT ||--o{ ERP_FINANCE_RECEIPT : "收款" ERP_PURCHASE_IN ||--o{ ERP_FINANCE_PAYMENT : "采购入库→付款" ERP_PURCHASE_RETURN ||--o{ ERP_FINANCE_PAYMENT : "采购退货→退款" ERP_SALE_OUT ||--o{ ERP_FINANCE_RECEIPT : "销售出库→收款" ERP_SALE_RETURN ||--o{ ERP_FINANCE_RECEIPT : "销售退货→退款" ERP_ACCOUNT { bigint id PK varchar name "账户名称" decimal balance "当前余额" tinyint status "状态" } ERP_FINANCE_PAYMENT { bigint id PK varchar no "付款单号" bigint account_id FK "结算账户" bigint in_id FK "采购入库单" decimal price "付款金额" datetime time "付款时间" } ERP_FINANCE_RECEIPT { bigint id PK varchar no "收款单号" bigint account_id FK "结算账户" bigint out_id FK "销售出库单" decimal price "收款金额" datetime time "收款时间" }

业务场景

场景一：采购付款

sequenceDiagram participant P2 as 采购员 participant F2 as 财务 participant ERP5 as ERP participant ACC as 结算账户 P2->>ERP5: 完成采购入库 F2->>ERP5: 查看待付款的采购入库单 F2->>ERP5: 选择结算账户，创建付款单 ERP5->>ACC: 扣减账户余额 ERP5->>ERP5: 记录付款流水

场景二：销售收款

sequenceDiagram participant S3 as 销售员 participant F3 as 财务 participant ERP6 as ERP participant ACC2 as 结算账户 S3->>ERP6: 完成销售出库 F3->>ERP6: 查看待收款的销售出库单 F3->>ERP6: 选择结算账户，创建收款单 ERP6->>ACC2: 增加账户余额 ERP6->>ERP6: 记录收款流水

结算账户

结算账户代表公司与供应商/客户之间的资金账户关系，每笔收付款都会影响对应账户的余额。

属性	说明
账户名称	如「XX 供应商结算账户」
当前余额	实时更新，付款减、收款加
状态	启用/禁用

IoT 物联网

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

IoT 模块是一个类阿里云物联网平台的设备管理平台。它可以接入海量设备，通过物模型定义设备能力，利用规则引擎处理设备数据，实现设备数据采集、远程控制和场景联动。

一句话：如果你的硬件设备需要接入云端管理，这里提供从设备注册到数据流转的完整链路。

解决什么问题

痛点	IoT 如何解决
设备接入协议多样	支持 MQTT/HTTP/CoAP/TCP/UDP/WebSocket/Modbus 等
设备数据格式不统一	物模型标准化设备能力定义
设备数据不知道如何处理	规则引擎 → 数据流转/场景联动/告警
设备固件升级困难	OTA 远程升级
需要对接第三方 IoT 平台	内置 EMQX 集成，可自定义协议

用户角色

graph LR subgraph 角色 IOT_ADMIN["IoT 管理员
定义产品
管理设备
配置物模型
设置规则引擎"] IOT_DEV["设备开发者
设备端开发
协议对接
OTA 升级"] IOT_OP["运维人员
监控设备状态
处理告警
数据分析"] end

平台架构

graph TB subgraph 设备层["设备层"] D1["传感器"] D2["网关"] D3["控制器"] D4["智能设备"] end subgraph 接入层["接入层（多协议）"] P1["MQTT"] P2["HTTP"] P3["CoAP"] P4["TCP/UDP"] P5["WebSocket"] P6["Modbus"] end subgraph 平台层["IoT 平台"] PRODUCT["产品管理
定义设备类型"] DEVICE["设备管理
注册/认证/状态"] MODEL["物模型
属性/服务/事件"] OTA["OTA 升级
固件远程更新"] end subgraph 处理层["数据处理层"] RULE["规则引擎
数据规则/场景联动/告警"] TD["TDengine
时序数据存储"] end 设备层 --> 接入层接入层 --> 平台层平台层 --> 处理层

物模型设计

物模型是 IoT 的核心概念，用标准化的方式描述设备「有什么属性、能做什么、会报告什么」：

graph TB subgraph 物模型["物模型 = 设备的数字化描述"] ATTR["属性 Property
设备的静态特征
例：温度、湿度、开关状态"] SERVICE["服务 Service
设备可执行的操作
例：开锁、重启、校准"] EVENT["事件 Event
设备主动上报的信息
例：告警、故障、完成通知"] end

规则引擎

设备生命周期

flowchart LR CREATE["创建产品
定义物模型"] --> REG["注册设备
获取认证信息"] REG --> ONLINE["设备上线
建立连接"] ONLINE --> WORK["正常工作
上报数据/接收指令"] WORK --> OTA2["OTA 升级"] OTA2 --> WORK WORK --> OFFLINE["设备下线"] OFFLINE --> ONLINE

支持的协议

协议	适用场景	特点
MQTT	物联网主流协议	轻量、发布订阅、QoS
HTTP	简单设备、Web 应用	通用性强
CoAP	低功耗设备	类 HTTP、UDP
TCP	自定义协议	灵活、高效
UDP	高频数据上报	低延迟
WebSocket	实时双向通信	浏览器友好
Modbus	工业设备	工控标准
EMQX	高性能 MQTT Broker	百万级连接
自定义协议	特殊设备	扩展开发

技术依赖

TDengine：时序数据库，用于存储设备上报的海量时序数据（需额外搭建）
EMQX：高性能 MQTT Broker（可选，用于大规模设备接入）

IM 即时通讯

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

IM 模块为你的平台提供内置即时通讯能力——无需集成第三方 IM SDK（如环信、融云），直接在系统内实现私聊、群聊、频道推送和音视频通话。特别适合需要「平台内通讯」的场景，如电商客服、企业内部沟通、社区私信等。

一句话：让你的用户在你的平台里就能聊天，数据和体验完全可控。

解决什么问题

痛点	IM 如何解决
第三方 IM SDK 费用高	自建 IM，零额外成本
用户数据存在第三方	聊天数据在自己的数据库
需要与业务系统打通	用户体系、好友关系与业务联动
音视频通话能力	集成 LiveKit，支持 WebRTC 通话

用户角色

graph LR subgraph 角色 IM_USER["普通用户
私聊/群聊
发送文字/图片/文件/语音
音视频通话"] IM_ADMIN["IM 管理员
管理群组
配置频道
管理敏感词
查看消息记录"] end

功能架构

graph TB subgraph 核心功能["核心功能"] MSG2["消息中心
私聊/群聊
文字/图片/文件/语音/视频"] FRIEND["好友关系
添加/删除/黑名单"] GROUP["群组管理
创建/加入/退出/禁言"] CHANNEL["频道推送
公告/通知广播"] CALL["音视频通话
基于 LiveKit
WebRTC"] end subgraph 辅助功能 EMOJI["表情管理"] SENSITIVE["敏感词过滤"] end subgraph 通信层["通信层"] WS["WebSocket 实时通信
local / redis / rocketmq
/ kafka / rabbitmq"] end 核心功能 --> 通信层辅助功能 --> 核心功能

核心 ER 图

erDiagram IM_USER ||--o{ IM_MESSAGE : "发送" IM_USER ||--o{ IM_FRIEND : "好友关系" IM_USER ||--o{ IM_GROUP_MEMBER : "群成员" IM_GROUP ||--o{ IM_GROUP_MEMBER : "包含" IM_GROUP ||--o{ IM_MESSAGE : "群消息" IM_CHANNEL ||--o{ IM_CHANNEL_MESSAGE : "频道消息" IM_CHANNEL ||--o{ IM_CHANNEL_MEMBER : "频道成员" IM_MESSAGE { bigint id PK bigint from_user_id FK "发送者" bigint to_user_id FK "接收者" bigint group_id FK "群组" tinyint type "消息类型" text content "消息内容" datetime create_time "发送时间" } IM_GROUP { bigint id PK varchar name "群名称" bigint owner_user_id FK "群主" tinyint status "状态" } IM_CHANNEL { bigint id PK varchar name "频道名称" tinyint type "频道类型" }

数据库表分组

分组	表数量	说明
消息中心	2 表	消息记录、消息会话
好友关系	2 表	好友、好友申请
群组管理	3 表	群组、群成员、群公告
频道推送	3 表	频道、频道成员、频道消息
音视频通话	2 表	通话记录、通话参与人
其他	4 表	表情、敏感词等

WebSocket 通信模式

graph TB subgraph 发送模式["消息发送模式（可切换）"] LOCAL["local
单机模式
开发调试用"] REDIS3["redis
Redis 广播
小规模集群"] ROCKET2["rocketmq
RocketMQ
高吞吐"] KAFKA2["kafka
Kafka
大规模"] RABBIT2["rabbitmq
RabbitMQ
企业级"] end

应用场景

场景	使用方式
电商客服	买家 ↔ 商家客服私聊
企业内部通讯	员工群聊、部门频道
社区私信	用户之间私聊
在线教育	学生 ↔ 老师、课程群聊 + 音视频
医疗咨询	患者 ↔ 医生私聊 + 音视频问诊

Vue3 管理后台

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

Vue3 管理后台是 RuoYi 的主推前端方案，也是业务功能最完整的前端项目。如果你不确定选哪个前端，就选这个——所有 14 个子系统的页面都在这里最先落地。

技术栈：Vue3 + TypeScript + Vite + Element Plus + Pinia

适合什么样的用户

用户画像	为什么选这个
追求稳定性的团队	所有功能最先在这里实现，经过最充分的测试
Element Plus 生态用户	组件库成熟、文档完善、社区活跃
需要最全业务功能	14 个子系统全部有对应页面
二次开发场景	代码结构清晰，模块化程度高

项目架构

graph TB subgraph 入口 MAIN["main.ts
应用入口"] end subgraph 核心层["核心层"] ROUTER["router/
路由配置"] STORE["store/
Pinia 状态管理"] UTILS["utils/
工具函数"] end subgraph 请求层["请求层"] AXIOS["utils/request.ts
axios 封装
baseURL / timeout / 拦截器"] API["api/
按模块划分 API"] MOCK["mock/
Mock 数据"] end subgraph 视图层["视图层（按子系统划分）"] SYS_V["views/system/
系统管理"] BPM_V["views/bpm/
工作流"] CRM_V["views/crm/
客户管理"] ERP_V["views/erp/
进销存"] MALL_V["views/mall/
商城"] end subgraph 组件层 COMPS["components/
公共组件"] DIRS["directives/
自定义指令"] PLUGINS["plugins/
插件"] end MAIN --> ROUTER MAIN --> STORE ROUTER --> 视图层视图层 --> API API --> AXIOS AXIOS --> UTILS

关键设计

axios 请求封装

baseURL: /api
timeout: 30000ms
拦截器:
 - 请求拦截：自动附加 Token
 - 响应拦截：统一错误处理、Token 过期跳转登录页

页面文件组织

每个业务页面通常包含：

views/erp/purchase/order/
 ├── index.vue # 列表页面
 ├── form.vue # 表单弹窗
 └── const.ts # 常量定义

权限控制

菜单和按钮都通过权限标识控制：

// 按钮权限示例
<el-button v-hasPermi="['erp:purchase-order:create']">新增</el-button>

// 菜单由后端返回，前端根据角色动态渲染

与其他前端的对比

维度	Vue3 管理后台	Vben5	Vue2
定位	主推，功能最全	新一代，架构更先进	经典版，兼容 Vue2
UI 库	Element Plus	Ant Design / Element Plus	Element UI
业务功能	✅ 全覆盖	🚧 逐步迁移中	✅ 全覆盖
开发体验	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
适用场景	新项目首选	追求最新技术栈	Vue2 存量项目

快速上手

# 1. 进入前端目录
cd yudao-ui-admin-vue3

# 2. 安装依赖
pnpm install

# 3. 启动开发服务器
pnpm run dev

# 4. 访问
http://localhost:80

Vben5 管理后台

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

Vben5 是 RuoYi 的新一代管理后台，基于 Vben Admin 5.x（Monorepo 大仓架构），架构设计更先进。支持 Ant Design Vue 和 Element Plus 两种 UI 组件库，你可以根据团队偏好自由选择。

技术栈：Vue3 + TypeScript + Vite + Vben5 + Ant Design Vue / Element Plus

适合什么样的用户

用户画像	为什么选这个
追求最新架构的团队	Monorepo + 更先进的状态管理 + 更强的类型约束
Ant Design 生态用户	支持 Ant Design Vue，UI 风格更国际化
大型项目团队	Vben 组件体系（Vxe Table / Vben Form / Vben Modal）更适合复杂表单和表格
愿意接受功能迁移中的状态	部分业务模块仍在从 Vue3 版迁移中

项目架构

graph TB subgraph Monorepo["Monorepo 大仓结构"] APPS["apps/
应用入口"] PKGS["packages/
共享包"] INTERNAL["internal/
内部工具"] end subgraph UI["双 UI 库支持"] ANT["Ant Design Vue
风格更国际化"] EP["Element Plus
风格更国产化"] end subgraph COMP["Vben 组件体系"] TABLE["Vben Vxe Table
高性能表格"] FORM["Vben Form
声明式表单"] MODAL["Vben Modal
弹窗管理"] DRAWER["Vben Drawer
抽屉组件"] end subgraph PAGES["页面结构（每页面三文件）"] INDEX["index.vue
页面入口"] FORM_V["form.vue
表单定义"] DATA["data.ts
数据逻辑"] end APPS --> UI APPS --> COMP APPS --> PAGES

核心优势

1. Monorepo 大仓架构

所有包在一个仓库中管理，依赖版本统一，代码复用更方便。共享的工具函数、类型定义、组件统一放在 packages/ 下。

2. 双 UI 库自由切换

// 可以选择使用 Ant Design Vue
import { Button, Table, Form } from 'ant-design-vue';

// 也可以选择 Element Plus
import { ElButton, ElTable, ElForm } from 'element-plus';

同一个业务逻辑，可以适配两种 UI 风格，这对需要交付给不同客户的项目尤其有价值。

3. 声明式组件体系

Vben 的组件体系让复杂表单和表格的开发效率大幅提升：

<!-- Vben Vxe Table：声明式列定义 -->
<vxe-grid v-bind="gridOptions">
 <!-- 内置分页、排序、筛选、导出 -->
</vxe-grid>

<!-- Vben Form：声明式表单 -->
<vben-form :schema="formSchema" />

功能迁移进度

模块	状态	说明
系统管理	✅ 已完成	用户/角色/菜单/部门等
基础设施	✅ 已完成	代码生成/文件/配置等
BPM 工作流	✅ 已完成（v2.6.1）	Ant Design 版本
CRM 客户管理	✅ 已完成（v2.6.1）	Ant Design 版本
Pay 支付中心	✅ 已完成（v2.6.1）	Ant Design 版本
Member 会员	✅ 已完成（v2.6.1）	Ant Design 版本
AI 大模型	✅ 已完成（v2.6.1）	Ant Design 版本
ERP 进销存	🚧 进行中	-
Mall 商城	🚧 进行中	-

快速上手

# 1. 进入目录
cd yudao-ui-admin-vben5

# 2. 安装依赖
pnpm install

# 3. 启动开发服务器
pnpm run dev

# 4. 访问
http://localhost:端口号

SaaS 多租户

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

SaaS 多租户让你用一套代码同时服务多个企业客户，每个客户（租户）只能看到自己的数据，彼此完全隔离。无论是做垂直 SaaS 产品还是企业内部多子公司管理，这都是不可或缺的能力。

两种方案：字段隔离（轻量级，适合中小规模）和数据库隔离（物理隔离，适合大规模 SaaS）。

适合什么样的用户

场景	推荐方案	原因
SaaS 创业初期	字段隔离	运维简单，一台数据库搞定
大型 SaaS 平台	数据库隔离	物理隔离，安全性高，可独立备份
企业内部多公司	字段隔离	公司数量有限，逻辑隔离足够
金融/医疗等强合规行业	数据库隔离	数据必须物理隔离

两种方案对比

graph TB subgraph COLUMN["方案一：字段隔离 COLUMN 模式"] direction TB C1["所有租户共享
同一数据库同一套表"] C2["每张表添加
tenant_id 字段"] C3["SQL 拦截器
自动拼接 WHERE tenant_id = ?"] C4["优点：运维简单、资源利用率高
缺点：逻辑隔离，安全性一般"] C1 --> C2 --> C3 --> C4 end subgraph DATASOURCE["方案二：数据库隔离 DATASOURCE 模式"] direction TB D1["主库：共享表
用户/菜单/配置/租户信息"] D2["租户库 A：业务表"] D3["租户库 B：业务表"] D4["租户库 C：业务表"] D5["优点：物理隔离、安全性高、可独立备份
缺点：运维复杂、资源利用率低"] D1 --> D2 D1 --> D3 D1 --> D4 D2 & D3 & D4 --> D5 end

详细对比

维度	字段隔离（COLUMN）	数据库隔离（DATASOURCE）
隔离级别	逻辑隔离	物理隔离
安全性	中等（依赖 SQL 拦截）	高（数据库级隔离）
资源利用率	高（共享连接池）	低（每租户独立连接）
运维复杂度	低（单库运维）	高（多库运维）
扩展性	受限于单库性能	可水平扩展
数据备份	需要按 tenant_id 筛选	每个租户独立备份
适用规模	百级租户	千级/万级租户
技术实现	MyBatis Plus 拦截器	dynamic-datasource

字段隔离实现原理

sequenceDiagram participant U as 用户（租户A） participant APP as 应用层 participant INTERCEPTOR as SQL 拦截器 participant DB as 共享数据库 U->>APP: 查询客户列表 APP->>INTERCEPTOR: SELECT * FROM crm_customer INTERCEPTOR->>INTERCEPTOR: 自动拼接 tenant_id = 'A' INTERCEPTOR->>DB: SELECT * FROM crm_customer
WHERE tenant_id = 'A' DB-->>APP: 只返回租户A的数据 APP-->>U: 显示客户列表

核心机制：通过 MyBatis Plus 的多租户插件，在执行任何 SQL 前自动添加 tenant_id 条件，对业务代码完全透明。

数据库隔离实现原理

基于 dynamic-datasource 动态数据源，请求进入时根据当前租户 ID 切换到对应的数据源：

spring:
 datasource:
 dynamic:
 primary: master  # 主库（共享表）
 datasource:
 master: # 主库配置
 url: jdbc:mysql://localhost:3306/ruoyi_master
 tenant_1: # 租户1的独立数据库
 url: jdbc:mysql://localhost:3306/ruoyi_tenant_1
 tenant_2: # 租户2的独立数据库
 url: jdbc:mysql://localhost:3306/ruoyi_tenant_2

租户套餐管理

graph LR PACKAGE1["基础版套餐
系统管理 + 基础功能"] PACKAGE2["专业版套餐
基础版 + CRM + ERP"] PACKAGE3["旗舰版套餐
全部功能"] 租户A["租户 A"] --> PACKAGE1 租户B["租户 B"] --> PACKAGE2 租户C["租户 C"] --> PACKAGE3

每个租户可以绑定一个套餐，套餐定义了该租户可见的菜单和可用功能。支持套餐到期自动禁用。

代码生成进阶

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

代码生成器是 RuoYi 开发效率的「核武器」。常规的单表 CRUD 已经不能满足复杂业务场景，这里介绍三种进阶生成模式，覆盖了企业开发中最常见的复杂页面形态。

有了这些能力，一个包含主子表、审批流的复杂业务页面，从「写几天」变成「配几分钟」。

适合什么样的用户

场景	推荐模式	效果
订单+明细	主子表-标准模式	同一弹窗，主子表同框编辑
工单+工序	主子表-内嵌模式	列表内直接展开子表
采购订单+明细	主子表-ERP 模式	主子表独立列表，独立表单
部门树/分类树	树形表模式	自动生成树形表格
移动端页面	uni-app 模式	生成适配 H5/小程序的页面

三种主子表生成模式

graph TB subgraph 标准模式["模式一：标准模式"] S1["主表列表页"] S2["点击新增 → 弹窗"] S3["弹窗内：主表表单 + 子表表格
在同一弹窗中编辑"] S1 --> S2 --> S3 end subgraph 内嵌模式["模式二：内嵌模式"] I1["主表列表页"] I2["展开行 → 内嵌子表
主表行下方直接显示子表"] I1 --> I2 end subgraph ERP模式["模式三：ERP 模式"] E1["主表独立列表"] E2["子表独立列表
（通过主表 ID 关联）"] E3["主表独立表单"] E4["子表独立表单"] E1 --> E2 E3 --> E4 end

各模式适用场景

模式	适用场景	用户体验	代表业务
标准模式	主子表数据量小，主表+子表需要一起填写	⭐⭐⭐⭐ 操作流畅	问卷+题目、配置+配置项
内嵌模式	需要快速查看子表数据，不想跳转	⭐⭐⭐⭐⭐ 信息密度高	工单+工序、任务+子任务
ERP 模式	主子表各有独立业务逻辑，数据量大	⭐⭐⭐ 灵活度高	采购订单+明细、销售订单+明细

树形表代码生成

graph LR DEPT["部门表
id / parent_id / name"] GEN["代码生成器
识别 parent_id 字段"] OUT["生成树形表格页面
el-tree + 拖拽排序"] DEPT --> GEN --> OUT

支持无限层级，自动生成展开/折叠、拖拽排序、新增子节点等功能。

uni-app 代码生成

为移动端生成完整的页面代码，支持：

列表页面（下拉刷新、上拉加载）
表单页面
详情页面
API 请求封装

前端版本支持

生成目标	Vue3 管理后台	Vben5	Vue2	uni-app
单表 CRUD	✅	✅	✅	✅
主子表-标准	✅	✅	✅	❌
主子表-内嵌	✅	✅	✅	❌
主子表-ERP	✅	✅	✅	❌
树形表	✅	✅	✅	❌

使用流程

在数据库中建好表结构
在「代码生成」菜单中导入表
配置生成选项（模块名、业务名、类名、生成模式）
预览并生成代码
将代码复制到项目中，配置菜单即可使用

BPM 工作流

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

BPM 工作流是企业的「审批中枢」——请假、报销、采购、合同、用章……几乎所有需要「多级审批」的场景，都能在这里建模和流转。基于 Flowable 引擎，提供仿钉钉/飞书和 BPMN 双设计器，非技术人员也能上手设计流程。

一句话：告别微信群审批、邮件审批、纸质审批，把审批流程变成结构化的可追溯系统。

解决什么问题

痛点	BPM 如何解决
审批流程靠口头/微信，无记录	所有审批留痕，可追溯每一步操作
审批规则靠人记忆，容易遗漏	流程模板固化规则，自动路由到正确审批人
跨部门审批沟通成本高	自动流转，无需人工通知
审批超时无人跟进	超时自动提醒，支持自动审批/跳过
组织变动导致审批人变化	审批人按角色/部门动态计算，不写死具体人

用户角色

graph LR subgraph 角色 ADMIN["流程管理员
设计流程模板
部署和发布流程"] APPLICANT["发起人
提交申请
查看审批进度
撤销申请"] APPROVER["审批人
审批/驳回/转办/加签
查看待办/已办"] COPYER["抄送人
接收审批结果通知
无需操作"] end

功能协作流程

sequenceDiagram participant A as 发起人 participant F as 流程引擎 participant P1 as 审批人1（部门主管） participant P2 as 审批人2（财务经理） participant B as 业务系统（如 ERP） A->>F: 发起流程（如采购申请） F->>B: 关联业务数据（采购订单 ID） F->>P1: 推送待办任务 P1->>F: 审批通过 F->>P2: 推送待办任务 P2->>F: 审批通过 F->>B: 回调：流程完成，更新业务状态 F->>A: 通知：申请已通过 Note over F: 若任一审批人驳回
流程回退到发起人

双设计器对比

graph TB subgraph SIMPLE["SIMPLE 设计器（仿钉钉/飞书）"] S1["拖拽式操作"] S2["适合简单审批链"] S3["学习成本低"] S4["非技术人员可用"] end subgraph BPMN["BPMN 设计器"] B1["标准 BPMN 2.0"] B2["支持复杂分支/并行"] B3["需要一定学习"] B4["技术人员使用"] end SIMPLE -.->|复杂场景可升级| BPMN

特性	SIMPLE 设计器	BPMN 设计器
上手难度	⭐ 极低	⭐⭐⭐ 中等
适用人群	业务人员、HR、行政	开发人员、流程专家
支持节点	审批、抄送、条件分支	全部 BPMN 2.0 节点
并行分支	❌	✅
包容分支	❌	✅
子流程	❌	✅

审批操作全景

graph TB 审批节点 -->|通过| 下一节点审批节点 -->|驳回| 退回节点["退回指定节点
或退回到发起人"] 审批节点 -->|转办| 转办人["转给其他人处理
自己不再参与"] 审批节点 -->|委派| 委派人["委派他人处理
处理完回到自己"] 审批节点 -->|加签| 加签人["增加审批人
会签/或签"] 审批节点 -->|减签| 减签人["减少审批人"] 审批节点 -->|终止| 结束节点["流程直接结束
（特殊权限）"]

流程控制能力

控制类型	说明	典型场景
条件分支	根据表单数据走不同审批路径	金额 < 5000 无需总经理审批
并行分支	多人同时审批，都通过才继续	多部门并行会签
包容分支	多人同时审批，任一通过则继续	或签场景
触发节点	自动执行服务任务	审批通过后自动创建 ERP 单据
延迟节点	等待指定时间后继续	合同到期前 7 天提醒
超时审批	超时自动处理	48 小时未审批自动通过/拒绝
自动提醒	定时提醒待办	每天早上 9 点推送待办汇总

与业务系统的集成

graph TB BPM["BPM 流程引擎"] subgraph 集成场景 ERP_APPROVAL["ERP 采购审批
采购订单 → BPM 审批 → 自动入库"] CRM_APPROVAL["CRM 合同审批
合同草稿 → BPM 审批 → 合同生效"] OA_APPROVAL["OA 通用审批
请假/报销/用章/外出"] end BPM --> ERP_APPROVAL BPM --> CRM_APPROVAL BPM --> OA_APPROVAL

集成方式：业务模块通过 BPM 提供的 API 发起流程、查询审批状态、处理审批回调，无需关心 Flowable 底层细节。

消息队列

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

消息队列是子系统间异步通信的「中枢神经」。当 ERP 出库需要通知 WMS 更新库存、当商城支付成功需要给会员发放积分——这些跨模块的异步协作都通过消息队列完成。

设计哲学：业务代码只依赖 yudao-spring-boot-starter-mq 抽象接口，切换底层实现只需改一行配置。

适合什么样的用户

用户画像	推荐方案
开发调试阶段	Spring Event（默认，零依赖）
中小型项目	Redis Stream（持久化，支持消费者组）
企业级项目	RabbitMQ（稳定可靠，运维成熟）
高吞吐场景	RocketMQ（阿里系，分布式事务）
大数据场景	Kafka（日志、埋点、数据管道）

架构设计

graph TB subgraph 业务层["业务代码层（只依赖抽象）"] P["生产者
MessageProducer.send()"] C["消费者
MessageConsumer.onMessage()"] end subgraph 抽象层["抽象层 yudao-spring-boot-starter-mq"] API["统一 API
Message / MessageProducer / MessageConsumer"] end subgraph 实现层["实现层（五选一）"] SE["yudao-spring-boot-starter-mq-spring-event
Spring Event（默认）"] REDIS["yudao-spring-boot-starter-mq-redis
Redis Stream"] RABBIT["yudao-spring-boot-starter-mq-rabbitmq
RabbitMQ"] ROCKET["yudao-spring-boot-starter-mq-rocketmq
RocketMQ"] KAFKA["yudao-spring-boot-starter-mq-kafka
Kafka"] end P --> API C --> API API --> SE API --> REDIS API --> RABBIT API --> ROCKET API --> KAFKA

五种实现对比

实现	持久化	消费模式	适用场景	切换配置
Spring Event	❌ 内存级	广播	开发调试	默认
Redis Stream	✅	集群消费/广播	中小型项目	`yudao.mq.type=redis`
RabbitMQ	✅	多种模式	企业级项目	`yudao.mq.type=rabbitmq`
RocketMQ	✅	集群/广播/顺序	高吞吐、事务消息	`yudao.mq.type=rocketmq`
Kafka	✅	分区消费	大数据、日志	`yudao.mq.type=kafka`

使用示例

定义消息

// 1. 定义消息类，实现 Message 接口
@Data
public class OrderPaidMessage implements Message {
 private Long orderId;
 private Long userId;
 private Integer amount;
}

发送消息

@Resource
private MessageProducer messageProducer;

public void payOrder(Long orderId) {
 // 业务处理...

 // 发送消息
 OrderPaidMessage message = new OrderPaidMessage();
 message.setOrderId(orderId);
 message.setUserId(getCurrentUserId());
 message.setAmount(order.getAmount());
 messageProducer.send(message);
}

消费消息

@Component
public class OrderPaidConsumer implements MessageConsumer<OrderPaidMessage> {

 @Override
 public void onMessage(OrderPaidMessage message) {
 // 发放积分
 memberService.addPoints(message.getUserId(), message.getAmount());

 // 更新库存
 stockService.decreaseStock(message.getOrderId());
 }
}

子系统间的典型消息流

sequenceDiagram participant MALL as 商城模块 participant MQ as 消息队列 participant WMS as 仓库模块 participant MEMBER as 会员模块 MALL->>MALL: 用户支付成功 MALL->>MQ: 发送「订单已支付」消息 MQ->>WMS: 消费消息 → 扣减库存 MQ->>MEMBER: 消费消息 → 发放积分 Note over WMS,MEMBER: 两个消费者独立执行，互不影响

切换方式

只需修改配置文件：

# 从 Spring Event 切换到 Redis Stream
yudao:
 mq:
 type: redis  # 改成 redis / rabbitmq / rocketmq / kafka

无需修改任何业务代码。

Pay 支付中心

Mon, 01 Jan 0001 00:00:00 +0000

核心定位

Pay 支付中心是平台的「统一收银台」。商城卖东西要收款、ERP 采购要付款、会员充值要收款——所有这些收付款场景都通过支付中心统一完成，业务模块不需要关心底层是微信支付还是支付宝。

一句话：对接一次支付中心，所有业务模块都能收付款。

解决什么问题

痛点	支付中心如何解决
每个业务单独对接微信/支付宝	统一对接一次，所有业务复用
支付渠道切换需要改业务代码	渠道变更对业务透明
支付回调处理分散	统一回调 → 分发到各业务模块
支付流水无处可查	支付中心记录所有流水，统一对账

用户角色

graph LR subgraph 角色 DEV["开发者
对接支付 API
处理支付回调"] ADMIN2["运营/财务
查看支付流水
处理退款
对账"] ENDUSER["终端用户
发起支付
查看支付结果"] end

架构设计

graph TB subgraph 业务层["业务模块（支付调用方）"] MALL["商城
订单支付"] ERP2["ERP
采购付款"] OTHER["其他模块
充值/转账"] end subgraph 支付中心["支付中心 yudao-module-pay"] API_LAYER["API 层
PayOrderApi / PayRefundApi"] CHANNEL["渠道适配层
PayClient 统一客户端"] CALLBACK["回调处理层
统一回调 → 分发业务"] end subgraph 渠道层["支付渠道"] WXPAY["微信支付
公众号/小程序/扫码"] ALIPAY["支付宝
PC/Wap/转账"] MOCK["模拟支付
开发调试用"] end 业务层 --> API_LAYER API_LAYER --> CHANNEL CHANNEL --> 渠道层渠道层 --> CALLBACK CALLBACK --> 业务层

支付应用设计

graph TB subgraph 应用隔离 APP1["支付应用：商城订单
回调地址：/mall/order/callback
订单前缀：MALL-"] APP2["支付应用：ERP 采购
回调地址：/erp/purchase/callback
订单前缀：ERP-"] APP3["支付应用：会员充值
回调地址：/member/recharge/callback
订单前缀：MBR-"] end

每个业务模块对应一个「支付应用」，拥有独立的回调地址和订单编号前缀，确保支付回调能准确路由到正确的业务处理逻辑。

支付全流程

sequenceDiagram participant U as 用户 participant BIZ as 业务系统（商城） participant PAY as 支付中心 participant CH as 支付渠道（微信/支付宝） U->>BIZ: 提交订单，点击支付 BIZ->>PAY: 创建支付单 PayOrderApi PAY->>CH: 发起支付请求 CH-->>U: 弹出支付页面 U->>CH: 完成支付（扫码/密码） CH-->>PAY: 异步回调：支付成功 PAY->>PAY: 更新支付单状态 PAY->>BIZ: 回调通知：订单已支付 BIZ->>BIZ: 更新订单状态 BIZ-->>U: 显示支付成功

支持的支付方式

渠道	支付方式	适用场景
微信支付	公众号支付	微信公众号内 H5 商城
微信支付	小程序支付	微信小程序商城
微信支付	转账	佣金提现、退款
支付宝	PC 支付	PC 端商城
支付宝	Wap 支付	移动端 H5 商城
支付宝	转账	佣金提现、退款
模拟支付	模拟	开发调试，无需真实账号

依赖关系

Mall 商城 → Pay 支付中心 ← ERP 进销存
 ↑
 系统管理模块（权限）

商城和 ERP 都依赖支付中心，支付中心依赖系统管理模块提供权限和配置管理。

更新日志

Mon, 01 Jan 0001 00:00:00 +0000

版本演进

RuoYi-Vue-Pro 从 v2.0.0 起步，持续迭代至今，总代码量约 26 万行（源码 16 万行，注释 6 万行，单元测试 1121+ 个）。

v2.6.1（2025-07-19）重点更新

Vben5 + Ant Design 大规模迁移：

迁移模块	状态
BPM 工作流	✅ 完成
CRM 客户管理	✅ 完成
Pay 支付中心	✅ 完成
Member 会员中心	✅ 完成
AI 大模型	✅ 完成
Vben5 + Element Plus 代码生成示例	✅ 新增

月度更新记录

时间	主要更新
2026-05	系统优化和 Bug 修复
2026-04	功能迭代
2026-03	功能迭代
2026-02	功能迭代
2026-01	功能迭代
2025-12	功能迭代
2025-11	功能迭代
2025-10	功能迭代
2025-09	功能迭代
2025-08	功能迭代
2025-07	v2.6.1：Vben5 + Ant Design 大规模迁移

技术指标

指标	数值
总代码行数	259,995
源码行数	161,332
注释行数	59,755
单元测试数	1,121+
业务子系统	14 个
数据库表总数	300+
支持前端版本	4 个（Vue3 / Vben5 / Vue2 / uni-app）