SpringBoot3+Vue3 最推荐的开源 OA 系统 2026：流程驱动、资源闭环、多端互通

SpringBoot3+Vue3 最推荐的开源 OA 系统 2026：流程驱动、资源闭环、多端互通

🌐 文档地址 ：https://ruoyioffice.com

📦 源码1·GitHub ：https://github.com/yuqing2026/ruoyi-office

📦 源码3·Gitee ：https://gitee.com/yqzy1688/ruoyi-office

💬 微信：17156169080（备注「RuoYi Office」）
一句话 ：2026 年选一套 SpringBoot3 + Vue3 的 OA，不要只数菜单有多少。真正能落地的产品，要同时满足三件事------流程驱动 （改审批链不改业务代码）、资源闭环 （会议室/公车/印章先占后还）、多端互通（电脑发起、手机审批，同一套待办）。RuoYi Office 就是按这三条尺子长出来的参考实现。

▲ 三条尺子：Flowable 驱动 12 类单据；用印/会议室/公车占用与归还闭环；PC（Vben）与 UniApp 共用 process key

---

引言：2026 年搜「OA 系统推荐」，真正该看什么

很多人打开搜索框，输入的是「开源 OA」「SpringBoot Vue3 办公系统」。点进去却经常看到三种文：

• 功能目录：公文、会议、用车、用印......列完 9 个模块就结束；
• 框架盘点：把后台脚手架、低代码平台、协同套件放在一张表里横评；
• 部署教程：Docker 起来了，但不知道日常办公怎么跑。

这些都有价值，但解决不了实施时最常被追问的三句话：

实施现场的原话	其实在问什么
「请假改成三级审批，要改代码吗？」	流程能不能在设计器里改，业务单据还认不认
「会议室白板被涂掉，两个部门同时订」	资源有没有占用与冲突校验，批完能不能还回来
「领导出差，电脑登不了，手机能不能批」	PC 和 App 是不是同一套流程、同一份待办

结论先说： 2026 年推荐一套 SpringBoot + Vue3 OA，标准不是「模块最多」，而是 流程驱动 + 资源闭环 + 多端互通 能不能同时成立。下面用 RuoYi Office 的真实源码和页面，把这三条尺子落到用印、公文、会议室、工单四个场景上。

---

一、三条尺子：为什么不是「功能越多越好」

OA 是 Business Process Management（BPM，业务流程管理）在办公域的落地。轻协同工具能解决「发个申请」，解决不了「批完之后资源给谁、什么时候还、手机能不能接着办」。

尺子	定义	做不到会怎样
流程驱动	单据只负责业务字段，谁审、会签还是或签、条件分支，全部交给 Flowable 流程定义	每种单写一套状态机，改审批链就要发版
资源闭环	提交时校验时段冲突；审批通过才占用；归还/取消释放；台账可追	会议室撞档、印章外借对不上、公车钥匙不知在谁手上
多端互通	同一 processDefinitionKey，PC 与 App 共用待办、同一张业务单	电脑能办、手机只能看列表，领导出差流程就停

RuoYi Office 的 OA 协同域不是独立小系统，而是一体化平台里的一组业务：公文、会议室、公车、用印、办公用品、出差、汇报、云盘、工单，外加企业邮箱。它们共用同一套用户、组织、权限、字典和 Flowable 引擎。

技术栈锚点（2026）：

层	选型
后端	Spring Boot 3.5 + Java 17 + Flowable 7
PC	Vue3 + Vben Admin + Ant Design Vue
移动	UniApp + Vue3，菜单带 mobile_path
单据回调	FlowBillService：状态回写 + onProcessApproved 等钩子

---

二、流程驱动：12 类单据，一把枚举对齐流程 key

流程驱动的第一块砖，不是设计器，而是 单据类型和流程定义 key 一一对应 。OA 模块用 OaBillTypeEnum 把编号、名称、流程 key 绑死：

public enum OaBillTypeEnum implements BillTypeEnum {
    OA_CAR_APPLY_BILL("101", "用车申请单", "oa_car_apply_bill"),
    OA_CAR_RETURN_BILL("102", "还车申请单", "oa_car_return_bill"),
    OA_SEAL_APPLY_BILL("103", "用印申请单", "oa_seal_apply_bill"),
    OA_MEETING_ROOM_BOOKING("104", "会议室预定申请单", "oa_meeting_room_booking"),
    OA_OFFICE_DOC_SEND("105", "公文发文", "oa_office_doc_send"),
    OA_OFFICE_DOC_RECEIVE("106", "公文收文", "oa_office_doc_receive"),
    OA_OFFICE_DOC_OUTSIDE("107", "外部收文", "oa_office_doc_outside"),
    OA_SUPPLY_APPLY_BILL("108", "办公用品领用申请单", "oa_supply_apply_bill"),
    OA_BUSINESS_TRIP("109", "出差申请单", "oa_business_trip"),
    OA_TRAVEL_REIMBURSE("110", "差旅报销单", "oa_travel_reimburse"),
    OA_WORK_REPORT("111", "工作汇报", "oa_work_report"),
    OA_TICKET_BILL("120", "工单", "oa_ticket_bill");
}

提交单据时，业务服务只做三件事：落库、按枚举取出 processDefinitionKey、调用 processInstanceApi.submitProcessInstance，把单据 id 当成 businessKey。审批链怎么走，是流程模型的事。

流程结束后，BPM 不直接改业务表。统一接口是 FlowBillService：

public interface FlowBillService<T extends BillTypeEnum> {
    T getSupportedBillType();
    void updateProcessStatus(String businessKey, Integer status);

    default void onProcessApproved(String businessKey) { }
    default void onProcessRejected(String businessKey) { }
    default void onProcessCancelled(String businessKey) { }
    default void deleteBill(String businessKey) { }
}

updateProcessStatus 负责把「审批中 / 通过 / 驳回 / 取消」写回单据；onProcessApproved 才做领域动作------发文生成收文、会议室注册会前提醒、工单匹配 SLA。BPM 模块只发事件，OA 自己接，边界清楚。

设计决策：

决策点	方案	理由
流程 key 放哪	枚举第三段，不写死在 Service	改 key 只改一处，提交与回调共用
审批人怎么配	流程设计器 + 候选人策略	角色/部门负责人/发起人自选，不进业务代码
通过后业务动作	onProcessApproved 钩子	避免在 Flowable TaskListener 里依赖所有业务包

---

三、场景一：用印外借------冲突校验 + 借还状态机

行政最怕的不是「没人申请」，而是 章借出去对不上。现场用印只要登记；外借必须回答：哪枚章、何时借、何时还、这段时间有没有别人也在借。

用印申请详情能看见单据编号、用印方式、预计借用/归还时间、审批状态：

▲ 用印详情不是一张空表：用印方式、印章、预计使用/归还时间、附件和流程状态在同一页，才能谈「资源闭环」

提交外借时，先做时段冲突，再启流程。useMode == 2 才校验------现场用印不占外借日历：

@Override
public Long submitSealApplyBill(SealApplyBillSaveReqVO saveReqVO) {
    if (StringUtils.isBlank(saveReqVO.getBillCode())) {
        saveReqVO.setBillCode(BillCodeUtils.generateBillCode(SystemEnum.OA, OaBillTypeEnum.OA_SEAL_APPLY_BILL));
    }
    // 仅外借用章校验时段重叠
    if (saveReqVO.getUseMode() != null && saveReqVO.getUseMode() == 2) {
        validateTimeConflict(saveReqVO);
    }
    SealApplyBillDO sealApplyBill = BeanUtils.toBean(saveReqVO, SealApplyBillDO.class)
            .setProcessStatus(BpmTaskStatusEnum.RUNNING.getStatus());
    sealApplyBillMapper.insertOrUpdate(sealApplyBill);

    Map<String, Object> vars = BpmProcessVariableUtils.buildBillVariables(
            saveReqVO, BpmProcessVariableUtils.ofFields("useMode", PV_SEAL_USE_MODE), null);
    String processInstanceId = processInstanceApi.submitProcessInstance(
            Long.valueOf(saveReqVO.getCreator()),
            new BpmProcessInstanceCreateReqDTO()
                    .setProcessDefinitionKey(OaBillTypeEnum.OA_SEAL_APPLY_BILL.getProcessDefinitionKey())
                    .setVariables(vars).setBusinessKey(String.valueOf(sealApplyBill.getId()))
    ).getCheckedData();
    sealApplyBillMapper.updateById(new SealApplyBillDO()
            .setId(sealApplyBill.getId()).setProcessInstanceId(processInstanceId));
    return sealApplyBill.getId();
}

冲突算法盯两类单据：审批中的外借单，以及审批已通过且状态仍是「外借中」的单。区间重叠用三种包含关系覆盖，避免「你的开始落在别人中间」漏检。

用印状态	含义	谁来切
待用印	审批通过，章还没拿走	onProcessApproved
外借中	已借出未还	行政确认借出
已归还	闭环完成	确认归还
逾期	超过预计归还时间	定时或手工标记

useMode 还会作为流程变量 sealUseMode 送进 Flowable，条件网关可以走「现场用印简化链 / 外借加行政确认」。这就是流程驱动：业务字段既服务台账，也服务分支。

移动端有独立的用印列表、新建、详情（pages-oa/seal/），process key 仍是 oa_seal_apply_bill。电脑填单、手机批，不拆两套流程。

---

四、场景二：公文发文------审批通过自动生成收文

公文难在「发出去之后」。Word 在微信群里转发，主送部门说没收到，抄送部门说不知道要不要办。正确模型是：发文是一张单，收文是下游自动生成的多张单。

发文详情能看到文号、标题、主送/抄送部门、正文或套红文件，以及审批轨迹：

▲ 发文详情要能看见主送/抄送部门和文号；审批通过后，这些部门会各自落到收文台账，而不是靠群转发

OfficeDocSendServiceImpl.onProcessApproved 在发文流程通过后，按主送、抄送拆部门，逐条插入收文，并复制附件：

@Override
public void onProcessApproved(String businessKey) {
    Long sendId = Long.parseLong(businessKey);
    OfficeDocSendDO sendBill = officeDocSendMapper.selectById(sendId);
    if (sendBill == null) {
        return;
    }
    if (StringUtils.isNotBlank(sendBill.getMainReceiveDeptIds())) {
        generateReceiveRecords(sendBill, sendBill.getMainReceiveDeptIds(),
                sendBill.getMainReceiveDeptNames(), RECEIVE_TYPE_MAIN); // 主送需办理
    }
    if (StringUtils.isNotBlank(sendBill.getCcDeptIds())) {
        generateReceiveRecords(sendBill, sendBill.getCcDeptIds(),
                sendBill.getCcDeptNames(), RECEIVE_TYPE_CC); // 抄送仅知悉
    }
}

收文记录会重新编号（oa_office_doc_receive），带上原文号、密级、缓急、正文和附件副本，并把 creator 清掉------收文要由接收部门签收认领，不能假装「发文经办人已经收了」。

设计点	做法	价值
主送 vs 抄送	receiveType 0/1	办理义务不同，列表可筛
附件	发文附件复制到每条收文	接收部门不翻原单
流程	收文另有 oa_office_doc_receive	签收、批示、办理可再走审批
文号	代字 + 年份 + 序号拼 GB 风格	台账检索按文号，不按聊天记录

这是流程驱动的典型后置动作：BPM 只说「这张发文过了」；OA 自己决定「给哪些部门生成收文」。群转发做不到这件事。

---

五、场景三：会议室------冲突、条件审批、会前提醒

会议室是资源闭环最直观的例子。白板划时段会被涂改；系统必须在提交那一刻回答「这间房这段时间有没有别人」。

预订详情要能看见房间、开始/结束时间、参会人、是否需要审批：

▲ 预订详情同时承载时段、房间和审批状态；冲突在提交时拦，提醒在审批通过后注册

提交链路：校验时间合法 → 校验冲突 → 写入「待使用」→ 把房间的 needApproval 放进流程变量 → 启动 oa_meeting_room_booking。

@Override
public Long submitMeetingRoomBooking(MeetingRoomBookingSaveReqVO saveReqVO) {
    validateMeetingTime(saveReqVO);
    validateTimeConflict(saveReqVO);

    MeetingRoomBookingDO booking = BeanUtils.toBean(saveReqVO, MeetingRoomBookingDO.class)
            .setProcessStatus(BpmTaskStatusEnum.RUNNING.getStatus())
            .setUseStatus(0); // 待使用
    meetingRoomBookingMapper.insertOrUpdate(booking);

    Boolean needApproval = false;
    if (saveReqVO.getRoomId() != null) {
        var room = meetingRoomService.getMeetingRoom(saveReqVO.getRoomId());
        if (room != null && room.getNeedApproval() != null) {
            needApproval = room.getNeedApproval();
        }
    }
    Map<String, Object> vars = BpmProcessVariableUtils.buildBillVariables(saveReqVO);
    vars.put(PV_MEETING_ROOM_NEED_APPROVAL, needApproval);
    // submitProcessInstance：key = oa_meeting_room_booking
    // ...
    return booking.getId();
}

冲突查询只盯 useStatus in (0, 1)（待使用、使用中），三种区间重叠。小会议室可以 needApproval = false，流程变量让条件网关走「免批占用」；大会议室必须过部门负责人。

审批通过后注册会前提醒；驳回、取消、撤回则撤掉提醒，避免「会已取消还推送」：

@Override
public void onProcessApproved(String businessKey) {
    MeetingRoomBookingDO booking = meetingRoomBookingMapper.selectById(Long.parseLong(businessKey));
    if (booking != null) {
        registerMeetingReminder(booking); // 按 reminderType 计算 planSendTime
    }
}

@Override
public void onProcessCancelled(String businessKey) {
    cancelMeetingReminder(Long.parseLong(businessKey));
}

公车申请是同一套算法换了资源对象：提交校验车辆时段，还车单回写里程与费用。用印外借、会议室、公车，底层都是 区间重叠三分支 + 占用状态机。

和会议室不同的是，公车拆成两张单、两个流程 key：oa_car_apply_bill 管「能不能出车」，oa_car_return_bill 管「车回来没有」。申请通过后车辆进入使用中；还车单把实际里程、油费、违章备注写回台账，再把使用状态打成已归还。少了还车这一环，占用永远关不掉，后面的人会一直看到「车不在」。

资源	占用入口	释放入口	冲突对象
会议室	预订审批通过	会议结束 / 取消预订	同一 roomId 的时段
印章（外借）	审批通过且借出	确认归还	同一 sealId 的外借区间
公车	用车申请通过	还车单通过	同一 carId 的出车区间

---

五附、OA 单据最小数据模型（方便二开对照）

实施和二开最常问「到底几张表」。协同域不是一张万能办公表，而是 台账 + 单据 成对出现：

业务	台账（主数据）	单据（过程数据）	流程 key
用印	印章档案	用印申请	oa_seal_apply_bill
会议室	房间档案（含是否需审批）	预订单	oa_meeting_room_booking
公车	车辆档案	用车申请 + 还车单	oa_car_apply_bill / oa_car_return_bill
公文	套红模板、归档台账	发文 / 收文 / 外来文	oa_office_doc_*
用品	物品库存	领用申请	oa_supply_apply_bill
工单	处理组、SLA 规则	工单	oa_ticket_bill

公共字段几乎每张单据都有：bill_code、process_instance_id、process_status、dept_id、附件走通用关联表。二开新单据时，优先抄「枚举加一行 + Service 实现 FlowBillService + 提交时校验冲突」，不要再发明一套审批状态。

---

六、场景四：工单 SLA 与企业云盘------2026 还在补的办公能力

只做审批的 OA，2026 年已经不够。内部报修、IT 请求需要 SLA；合同范本、制度文件需要在线改而不是反复下载。

6.1 工单：审批通过 → 待分派 → 匹配 SLA

工单单据 key 是 oa_ticket_bill。流程通过后不是结束，而是进入服务台生命周期：

@Override
public void onProcessApproved(String businessKey) {
    TicketBillDO bill = ticketBillMapper.selectById(Long.parseLong(businessKey));
    TicketBillDO updateObj = new TicketBillDO();
    updateObj.setId(bill.getId());
    updateObj.setTicketStatus(TicketStatusEnum.PENDING_ASSIGN.getStatus());

    TicketSlaRuleDO slaRule = ticketSlaRuleService.matchSlaRule(bill.getPriority(), bill.getCategory());
    if (slaRule != null) {
        LocalDateTime baseTime = bill.getSubmittedTime() != null ? bill.getSubmittedTime() : LocalDateTime.now();
        if (slaRule.getResponseHours() != null) {
            updateObj.setResponseDeadline(baseTime.plusHours(slaRule.getResponseHours()));
        }
        if (slaRule.getResolveHours() != null) {
            updateObj.setResolveDeadline(baseTime.plusHours(slaRule.getResolveHours()));
        }
    }
    // 处理组存在则尝试自动分派，否则进工单池
}

能力	作用
优先级 × 类别匹配 SLA	响应时限、解决时限从规则来，不写死在代码
处理组自动分派	能派就派，派不了进工单池
工单池	服务台认领，避免「审批过了没人接」

工单池详情能看到优先级、截止时间和处理组，这是效果页，不是另一张列表：

▲ 审批通过只是工单生命的上半场；SLA 截止时间和处理组才决定会不会超时

6.2 云盘：目录权限 + 版本 + OnlyOffice

企业云盘解决「制度文件在微信里传丢」。能力分层是：目录树与分享 ACL、版本历史（恢复即新版本）、OnlyOffice 在线编辑。PC 有独立编辑路由 /oa/cloud/file-editor；App 有 pages-oa/file。办公用品领用通过后还可以一键转固进资产台账------OA 不再是信息孤岛。

---

七、多端互通：同一把 key，电脑发起、手机审批

多端互通不是「另外做一套 H5」。RuoYi Office 的约定是：

端	职责	流程身份
PC · Vben	复杂表单、设计器、台账、套打	processDefinitionKey + businessKey
App · UniApp	发起常用单、待办详情、底栏审批按钮	同一 key，菜单 mobile_path
待办中心	PC 工作台 / App 工作台 Tab	同一任务 id

UniApp 已覆盖用印、会议室、用车/还车、出差、报销、用品、汇报、云盘等 pages-oa/*。待办详情把业务单据、viewType 和底栏按钮嵌在同一页------领导出差只带手机，也能同意、驳回、加签。

移动端审批详情和 PC 详情吃的是同一套 viewType：待办可批、已办只读、抄送只看。按钮不是前端写死「同意/驳回」，而是按流程返回的 buttonsSetting 渲染。这一点保证了：你在设计器里关掉「转办」，手机底栏也不会出现转办。

工作台待办是唯一允许的「列表风」入口，用来说明待办聚合在哪：

▲ 用印、用车、请假、工单进同一待办中心；多端互通的关键是任务模型统一，不是各做各的消息盒子

---

八、和轻协同 / 自建脚手架怎么比

不做七家横评。只回答「钉钉/企微轻 OA」和「自己用 SpringBoot 从零搭」差在哪。

维度	轻协同（钉钉等）	从零自建后台	RuoYi Office
审批链	平台内配置，数据在对方云	自己写状态机	Flowable，模型可导出，私有化
资源占用	日程为主，印章/公车弱	每类资源自己算冲突	会议室/公车/用印同一套区间算法
公文闭环	审批附件	自己做发文收文	发文通过自动生成收文
移动端	强	往往 PC 优先	UniApp 同源待办
二开	受开放平台限制	完全可控，成本高	源码 + 代码生成 + 流程设计器
数据	多在公有云	自建库	私有化 MySQL，租户隔离

适用画像：

• 要私有化、要改流程、要 PC+App：优先这种 SpringBoot3 + Vue3 + Flowable 一体化。
• 只要群里点同意：轻协同更轻，不必上完整 OA。
• 只要 CRUD 脚手架：后台框架就够，不要指望它变成办公闭环。

HRM、CRM、ERP 是同一平台上的其它域，能否使用、如何授权以产品说明和商务沟通为准；本文只把 OA 协同讲清楚。

---

九、技术亮点小结

设计要点	实现方式	价值
单据对齐流程	OaBillTypeEnum 第三段 = process key	12 类单同一提交范式
回调解耦	FlowBillService 钩子	BPM 不依赖 OA 包
外借冲突	审批中 ∪ 外借中，三种区间重叠	章不会被两个人同时借走
发文→收文	onProcessApproved 按部门拆单	主送办理、抄送知悉
会议室变量	needApproval 进流程变量	小房间免批、大房间走链
会前提醒	通过注册、取消/驳回撤销	不推已作废会议
工单 SLA	优先级×类别匹配时限	审批结束后进入服务台时钟
多端	同一 key + UniApp 页面	电脑发起、手机审批

---

十、快速体验

在线演示：https://ruoyioffice.com/web/（账号 admin / admin123）

建议 8 步走通三条尺子：

1. 登录后打开工作台，看待办是否聚合了多种单据。
2. 新建一张用印申请，选外借，填预计借用/归还时间，故意和已有单重叠，看是否被拦。
3. 打开用印详情，核对编号、用印方式和审批区。
4. 打开一篇已通过的公文发文，再去收文台账看是否按主送/抄送生成。
5. 预定会议室，看时段冲突和「需审批」房间是否走流程。
6. 打开流程设计器，改用印或会议室的节点，不必改 Java。
7. 用手机或 H5（https://ruoyioffice.com/app/）进待办，批一张 OA 单。
8. 打开工单或云盘，感受审批之外的服务台与在线文档。

源码仓库：

平台	地址
GitHub	https://github.com/yuqing2026/ruoyi-office
GitCode	https://gitcode.com/zhouzhongyan/ruoyi-office
Gitee	https://gitee.com/yqzy1688/ruoyi-office

本地启动后端（默认端口 48080），前端在 Vben 仓库执行 pnpm dev:antd（5800）。流程模型需已发布对应 key，否则提交单据会提示找不到流程定义。

相关阅读（标题检索即可）：《OA 协同办公产品介绍：9 个业务域、1 套审批流、双端可办》《SpringBoot+Flowable 业务单据流程回调设计》《SpringBoot3+Flowable 审批条件分支》。

---

常见问题（FAQ）

2026 年 SpringBoot + Vue3 的开源 OA 怎么选？

先看三条：流程能不能在设计器改、会议室/用印/公车有没有占用闭环、手机能不能办同一张单。功能清单可以后看。RuoYi Office 是按这三条落地的参考实现，在线演示可直接点。

RuoYi Office 的 OA 支持自定义审批流程吗？

支持。基于 Flowable BPMN 引擎，OA 的 12 类单据通过 OaBillTypeEnum 绑定 process key。改节点、会签、条件分支在流程设计器完成，业务 Service 继续走 submitProcessInstance + FlowBillService。

和钉钉、企微自带 OA 有什么区别？

轻协同强在即时沟通和轻审批；RuoYi Office 强在私有化、公文发收联动、资源占用台账、以及和人事/资产等模块共用组织权限。数据要出公有云、审批链要跟组织架构深度绑定的团队，更适合后者。

只有 PC，没有 App 能用吗？

能。PC 管理端是完整能力。多端互通的意思是 同一套流程也可以在 UniApp 上办，不是强制上 App。演示环境同时提供 Web 与 H5。

办公用品、出差报销算不算 OA？

算协同办公域。用品有消耗/借用/转固；出差与报销双单联动。它们同样走 Flowable，不是独立小系统。

---

结语

2026 年再推荐一套 SpringBoot3 + Vue3 OA，不该只说「模块全」。流程驱动 让 12 类单据共用引擎；资源闭环 让章、车、会议室从占用走到归还；多端互通 让待办在电脑和手机是同一件事。RuoYi Office 把这三条写进了枚举、冲突校验和 onProcessApproved 钩子里------可跑、可改、可私有化。

你们团队现在卡在哪一条：流程改不动、资源对不齐，还是领导只能在电脑前批？评论区说说现状。

---

💡 想要体验 RuoYi Office 的强大功能？

🌐 在线演示：https://ruoyioffice.com/web/（账号 admin / admin123）

📦 源码仓库：GitHub：https://github.com/yuqing2026/ruoyi-office ｜ GitCode：https://gitcode.com/zhouzhongyan/ruoyi-office ｜ Gitee：https://gitee.com/yqzy1688/ruoyi-office

💬 技术咨询 ：添加微信 17156169080，备注「RuoYi Office」

⭐ 如果觉得不错，请给个 Star 支持一下！