企业官网建设流程全解析

找开源 OA 系统？看看这套 SpringBoot + Vue3 的 RuoYi Office 企业管理一体化平台

对熟悉若依（RuoYi）生态的 Java 开发者，这个项目值得关注的地方，是它已经把办公入口、组织权限、流程和表单放在了一个产品里。你可以从已有系统继续扩展，而不是只拿一个登录页和后台菜单开始拼。

SpringBoot + Vue3 技术栈和产品结构

先用一张表把技术和界面对上，后面看截图就容易理解了。

它不是把几种技术名称放到介绍页就结束。对使用者来说，设计好的表单需要有入口，发起的单据需要进入待办，处理结果需要能回看；对开发者来说，这些公共部分有了基础，后续才好集中精力处理项目自己的需求。

PC 首页把应用中心和办公待办放在一起

找 OA 时，很容易先比较菜单有多少。几十个模块往左边一排，看起来都挺完整。但员工每天打开系统，通常不是来研究模块划分的，而是想知道：今天有什么需要处理，之前提交的事情到哪了，常用入口在哪里。

[系统截图·现场截取] PC 工作台完整布局，包含应用中心、待办面板、通知公告和日历。截图于 2026-10-14，具体布局随版本和配置变化。

图中间是应用中心，下方是待办任务、我的单据、已办任务和抄送记录。它们看起来只是几个标签，回答的问题却不同：待办是“现在轮到我做什么”，我的单据是“我发出去的事情怎么样了”，已办用来回看处理记录，抄送则让需要知情的人有地方查。

右侧的通知、日程承担另一类工作：把需要知道的信息摆出来，不让所有消息都挤进审批列表。

这种布局对日常办公的意义，是把“找功能”和“处理事情”分开。第一次接触系统，可以从应用中心认识入口；熟悉之后，大部分时间直接看待办，不必每次先猜这件事属于哪个模块。

PC 首页也不是只能改一个欢迎语。产品有首页管理与组件化设计能力，可以调整布局和组件配置。需要注意，首页设计权限和默认工作台是否允许编辑受环境设置约束，并非任意账号都能改全公司的首页。我们更建议先把最常用的入口、待办和公告放好，再决定是否加统计图；首页不是越满越专业。

UniApp 移动办公不是把 PC 页面缩小

PC 适合同时看多项信息，手机适合快速找到入口、补充资料、处理一件事。如果只是把 PC 表格缩到手机宽度，功能虽然还在，实际操作却可能非常费劲。

RuoYi Office 的移动端采用独立的移动页面。底部划分首页、审批、工作台、消息和我的，工作台再按类别展示应用，顶部留出常用入口区域。

[系统截图·已有素材] 移动工作台。这里展示入口组织方式，不逐项展开业务规则；可见菜单取决于账号权限和配置。

这里有两个值得留意的细节。一个是常用功能可以单独组织，没必要让用户每天从长长的分类里翻。另一个是应用按组摆放，用户可以先选方向，再找具体入口，不用在手机上展开多层后台菜单。

手机上的“首页”和“工作台”也不用做成两个一样的页面。首页负责让用户了解自己的状态，工作台负责找到要办的事情。把这两种用途分清，才不容易出现到处都是按钮、却不知道先点哪里的情况。

技术上，PC 使用 Vue3，移动端采用 UniApp + Vue3，后端以 Spring Boot 为基础。对已有 Java 和 Vue 开发人员的团队，这是一套相对熟悉的技术组合。不过，采用跨端框架不等于每个自定义页面都已在所有终端验证过。选型时仍应拿自己计划使用的浏览器或小程序，检查关键表单、附件和审批操作。

Flowable 审批中心统一接收各类待办

企业里需要审批的事情来自不同部门。如果每个模块都有一套待办页面，主管就得每天逐个进去看，还容易遗漏。

RuoYi Office 将审批入口集中起来，手机上同样保留待办、我的、已办和抄送的分类。

[系统截图·已有素材] 移动审批待办。卡片展示单据、摘要、当前任务节点和操作入口，按钮由任务状态及配置决定。

列表卡片并不是只放一个标题。单据编号用于定位记录，摘要帮助判断内容，任务节点说明现在走到了哪里，接收时间帮助安排处理顺序。是否直接显示同意、拒绝，还是先进入详情办理，要结合具体任务来看。

我们不建议把“手机上能点同意”当作全部的移动审批体验。更重要的是，审批人是否看得懂材料、是否能找到前面的处理意见、需要补充信息时是否有清楚的操作路径。这些才是演示时值得花时间走一遍的地方。

PC 端适合展开看完整单据和流程关系，手机端适合随手办理。两端不需要长得一样，但同一张单据的状态与权限含义应保持一致，这也是项目验收时需要实际核对的内容。

FormCreate 表单设计配合可视化审批流程

再往后台看，表单设计和流程配置是两类不同的能力。

表单解决“要收集什么信息”。RuoYi Office 基于 FormCreate 提供表单设计器，输入、选择、日期、附件等组件放在左侧，中间是编辑画布，右侧调整属性。字段、排版、必填与填写说明可以集中维护，不必每改一次文字就去找某个页面文件。

[系统截图·已有素材] 表单设计器。图中单据只用于展示字段与布局能力，不展开其业务规则。

流程解决的则是“交给谁处理，按什么顺序走”。配置时可以考虑角色、岗位、部门负责人等人员来源，再决定多人处理方式和分支条件。进入实际单据后，流程视图把发起人、审批节点和分支关系展示出来，用户能知道自己的事情到了哪一步。

[系统截图·已有素材] 流程实例的可视化视图，用来查看节点关系和处理进度，不是流程编辑画面。

这两项能力放在一起，才形成一个比较完整的使用过程：设计收集信息的页面，配置处理规则，用户提交，任务进入审批中心，相关人员再查看处理状态。

这里也要划清低代码的用途。增加常规字段、调整页面排版，与连接外部系统、执行复杂业务校验，不是同一类工作。前者适合通过配置完成；后者通常还需要开发与测试。一个表单能预览出来，并不代表业务规则也自动齐了。

OA 源码二开先分清配置项和开发项

如果你是接企业项目的开发团队，这套产品更适合作为已有基础继续扩展，而不是只拿几张界面参考图。

我们建议先做一次小范围验证：选一个常用入口，配置一张表单和一条审批路线，用发起人和审批人两个账号分别走一遍，再从手机回看。这一圈下来，比单看完整菜单更容易判断是否适合。

评估二开工作量时，可以把需求分成两类。首页排版、常用入口、表单字段和审批人员规则，先看现有配置能不能覆盖；复杂数据关系、特殊交互、外部接口和业务结果回写，则单独列入开发清单。不要把所有需求都算成“再拖几个组件”。

拿源码还需要确认交付范围。PC、移动、后端分别包含什么，依赖哪些服务，后续升级如何合并，以及客户项目的使用授权覆盖到哪里，都应该在开始前说清楚。能修改源码，不自动等于可以转售源码或给别人再授权。

宇擎建议 哪些团队适合这套 OA 系统

如果你的目标是搭一套企业内部办公系统，需要 PC 管理界面，也需要员工和主管在手机上参与，RuoYi Office 值得认真看一遍。特别是已有 Java、Vue 团队，希望复用工作台、表单和流程基础，再做自己的特色部分的情况。

如果只是想学习几个后台页面，未必需要从完整产品开始；如果要求拿到公开仓库后就获得全部能力和持续更新，也要先确认版本边界。完全不准备投入部署、配置和维护人员的团队，则更适合先比较托管服务。

我们对 OA 的判断很朴素：菜单丰富只是起点，员工愿意打开、审批人找得到事情、管理员改得动规则，才更接近真正能用起来的系统。

想按本文的顺序看看界面，可以分别打开 PC 演示 和 移动端演示。先看首页，再看待办，最后回到表单和流程配置，比随机点菜单更容易形成判断。

关注我们，继续聊企业软件怎么设计、怎么用、怎么改。