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）