科技学院OA系统设计实战：Spring Boot与Vue3实现审批流程

去年上半年接了一个科技学院OA系统设计与实现的课题说白了就是给一所科技学院做一套内部办公平台。学校原来用的第三方OA挂在老服务器上流程写得很死教师请个假都要找管理员改表单会议室预约、设备报修这些日常操作更是绕来绕去。系统改一次需求贵不说接口封闭想接学校统一身份认证都费劲最后只能整体推倒重来。这篇博客不是简单贴代码我会把项目推进过程中的设计取舍、数据库建模、审批流轻量化实现、前后端联调、生产部署和踩坑经历都按真实顺序写出来。如果你正在做OA相关毕业设计、实验室项目或者想了解一套企业级办公系统从零怎么落地这篇内容应该比看官方文档更有参考价值。1. 项目定位与整体设计思路拆解1.1 院校OA和普通企业OA的差异在哪里很多人一听OA系统脑子里就是企业里的请假审批、报销流程、文件收发那套东西。实际进了科技学院这个场景需求会明显不一样。第一是组织结构学院有自己的特殊性教务处、科研处、学生处、后勤、各二级学院都有各自的管理边界审批链经常是“发起人 - 教研室主任 - 二级学院领导 - 职能部门 - 分管校领导”多级流转。第二是使用节奏学校有寒暑假和学期周期开学季、期末季的流程并发量会瞬间上去平时又很平稳。第三是外部系统对接OA不能是孤岛必须对接教务系统、科研管理系统和学校统一身份认证平台这决定了技术选型时接口开放性必须优先考虑。还有一个容易被忽略的点院校OA的操作使用者并不都是计算机专业的老师。很多行政老师年龄偏大对复杂界面的接受度低所以交互设计得尽量简单能点选就不要手动输入能默认就不要留空。这个需求会对前端设计产生直接影响后面我会详细说。1.2 自研还是采购现成OA我的选型逻辑不是没考虑过泛微、致远这类成熟产品。说实话如果只是“办公用起来”采购确实更快。但放到“科技学院”这个具体环境里问题就来了。我列了一个对比矩阵对比维度成熟商业OA泛微/致远自研定制系统上线速度快开箱即用慢至少2到3个月定制灵活性依赖厂商实施改流程周期长团队自己掌控随时调整二次开发成本需要熟悉厂商私有框架统一技术栈上手快系统对接往往需要额外购买接口模块可自行开发对接接口教学科研价值低黑盒为主可作为软件工程课程案例和科研平台长期维护成本授权费实施费高主要是人力维护成本对一个科技学院而言自研不只是“省钱”更核心的价值在于可掌控性和人才培养。学院计算机相关专业的学生、老师把OA当成实践平台可以做数据分析、流程优化、移动端适配等课题这个价值是商业产品给不了的。我最终选了自研核心出发点不是排斥商业软件而是要把系统的命脉握在自己手里。1.3 技术栈选定和背后的理由这套系统前后端分离前端用Vue 3 Element Plus后端用Spring Boot 2.7数据库MySQL 8.0缓存Redis权限认证用JWT Sa-Token。这里有一个很多人会问的点都已经用JWT了为什么还要用Sa-Token其实是Sa-Token本身内置了Token登录、权限认证、会话管理功能用起来比Spring Security简单太多在OA这种后台管理系统中完全够用而且对二次开发非常友好。前端选择Vue 3而不是Vue 2主要是考虑到Element Plus组件库的生态已经成熟表格、弹窗、表单、树形控件都在持续更新。模板语法和组合式API写起来也更清晰。数据库用MySQL 8是因为学校机房和学院服务器跑MySQL是常见现状运维熟悉出问题容易找人问。Redis主要用来做验证码缓存、在线用户状态、待办事项计数。文件存储直接用服务器本地目录加Nginx静态映射暂时没上OSS、MinIO因为校内文件量不大本地存储更容易控制权限。2. 数据库建模与核心模块剖析2.1 RBAC权限模型怎么落到表结构上OA系统最常见的权限模型就是RBAC也就是用户-角色-权限三层。虽然现在流行更细的ABAC但对学校这种相对固定的行政组织来说RBAC足够且易于理解。具体我设计了五张基础表用户表、角色表、用户角色关联表、菜单表、角色菜单关联表。用户表核心字段是id、username、password、real_name、department_id、position、phone、email、status。password存的是BCrypt加密后的哈希值不能存明文。department_id关联部门表这个字段很关键因为审批流里经常需要按部门找上级审批人。角色表就是role_name、role_code、remark这类基础字段。菜单表包括menu_name、parent_id、path、component、icon、sort_order这会直接跟前端动态路由绑定。CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(64) NOT NULL UNIQUE, password VARCHAR(255) NOT NULL, real_name VARCHAR(64) NOT NULL, department_id BIGINT, position VARCHAR(64), phone VARCHAR(20), email VARCHAR(128), status TINYINT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); CREATE TABLE sys_role ( id BIGINT PRIMARY KEY AUTO_INCREMENT, role_name VARCHAR(64) NOT NULL, role_code VARCHAR(64) NOT NULL UNIQUE, remark VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE sys_user_role ( user_id BIGINT NOT NULL, role_id BIGINT NOT NULL, PRIMARY KEY (user_id, role_id) ); CREATE TABLE sys_menu ( id BIGINT PRIMARY KEY AUTO_INCREMENT, parent_id BIGINT DEFAULT 0, menu_name VARCHAR(64) NOT NULL, path VARCHAR(128), component VARCHAR(128), icon VARCHAR(64), sort_order INT DEFAULT 0, visible TINYINT DEFAULT 1 ); CREATE TABLE sys_role_menu ( role_id BIGINT NOT NULL, menu_id BIGINT NOT NULL, PRIMARY KEY (role_id, menu_id) );这张表结构看起来简单实际操作中有一个坑权限变更后已经登录的用户不会立刻生效因为菜单是从前端路由里加载的。我当时的做法是每次进入系统时调一次“获取当前用户信息”接口后端把该用户拥有的菜单权限实时查出来返回前端再动态生成路由。这样管理员改了权限用户刷新页面就能生效不需要重新登录。在设计业务表的时候我坚持加一个created_by字段记录操作人ID。比如审批记录表、通知公告表都冗余了操作人姓名和部门名称。为什么冗余因为OA系统里的历史数据特别多如果每次查询都要连表去查用户表关联关系多了以后SQL会越写越复杂性能也会受影响。姓名和部门这种不常变化的数据冗余下来查询速度能快很多这种设计在报表统计时尤其好用。2.2 审批流程不引工作流引擎自己怎么设计这是整个系统最有争议的地方。一开始我也考虑过Activiti、Flowable这些开源工作流引擎后来果断放弃了。原因是学院的OA流程虽然种类多但节点结构相对固定比如请假流程就三级审批会议室预约就两级审批。引入重型工作流引擎要维护BPMN流程图、流程部署、引擎表对一个小团队来说学习成本和运维成本都偏高。我采用了一个轻量级的流程引擎设计用流程定义表保存每个流程的节点JSON数组用流程实例表记录当前走到哪个节点用任务表记录待办用审批记录表保存每一步的意见。核心表结构如下CREATE TABLE oa_process_definition ( id BIGINT PRIMARY KEY AUTO_INCREMENT, process_code VARCHAR(64) NOT NULL UNIQUE, process_name VARCHAR(128) NOT NULL, form_schema JSON, node_config JSON, status TINYINT DEFAULT 1 ); CREATE TABLE oa_process_instance ( id BIGINT PRIMARY KEY AUTO_INCREMENT, process_code VARCHAR(64) NOT NULL, business_type VARCHAR(32), business_id BIGINT, current_node INT DEFAULT 0, status VARCHAR(20) DEFAULT DRAFT, applicant_id BIGINT, applicant_name VARCHAR(64), department_name VARCHAR(128), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); CREATE TABLE oa_task_instance ( id BIGINT PRIMARY KEY AUTO_INCREMENT, instance_id BIGINT NOT NULL, node_index INT NOT NULL, node_name VARCHAR(64), assignee_type VARCHAR(20), assignee_id BIGINT, assignee_name VARCHAR(64), status VARCHAR(20) DEFAULT PENDING, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, finish_time DATETIME ); CREATE TABLE oa_approval_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, instance_id BIGINT NOT NULL, node_index INT, approver_id BIGINT, approver_name VARCHAR(64), action VARCHAR(20), comment VARCHAR(500), create_time DATETIME DEFAULT CURRENT_TIMESTAMP );node_config是一个JSON数组每一项代表一个审批节点比如[ { nodeName: 教研室主任审批, assigneeType: DEPARTMENT_LEADER, sort: 1 }, { nodeName: 学院领导审批, assigneeType: COLLEGE_LEADER, sort: 2 } ]assigneeType用来决定这个节点的审批人是谁。我实现了几种类型指定人员、部门负责人、分管领导、角色。这样配置流程的时候管理员只需要在页面上把节点排一下序、选好每个节点的审批人类型流程就生成好了。有一次领导临时说“请假流程中间要加一个教务处备案节点”我在后台流程定义里把JSON数组改了一下直接生效这种灵活性用商业OA反倒要做半天配置。流程状态我用的是状态机DRAFT草稿、PROCESSING审批中、APPROVED通过、REJECTED驳回、CANCELED撤回。驳回可以驳回到发起人也可以驳回到上一个节点我实现的是最常用的“驳回到发起人”发起人可以修改后重新提交也可以直接放弃。这种设计在OA实践中已经覆盖了绝大部分场景没必要把状态搞得太复杂。2.3 待办已办和通知消息的设计待办和已办是根据任务表实时查出来的。一个用户在待办里看到的数据就是oa_task_instance表里assignee_id等于当前用户ID而且status为PENDING的记录。点进去后页面根据instance_id加载流程详情和表单数据。已办则是当前用户所有finish_time不为空的任务记录。这个实时查询方案理论上没问题但有一个性能隐患列表页如果每次都去查流程实例表、任务表、审批记录表做多表关联数据量大了以后会越来越慢。我后来做了两个优化第一在任务表里直接冗余了流程名称、申请人、申请部门、发起时间这些展示字段列表页单表查询就够了第二给assignee_id和status建了组合索引这两个字段的查询频率最高。ALTER TABLE oa_task_instance ADD INDEX idx_assignee_status (assignee_id, status);通知消息有站内信和系统弹窗两种。每次产生新的待办任务时除了写任务表我还会往消息表插入一条record。前端通过WebSocket订阅消息主题登录认证成功后就建立连接收到未读消息数量变化时右上角小红点实时刷新。这里没有引入MQ就用了Spring Boot自带的STOMP消息功能院校OA的实时消息体量不大简单方案完全够用。3. 核心功能实操从登录到审批链路打通3.1 Spring Boot 后端工程搭建与依赖准备项目用Maven管理依赖父工程用的是Spring Boot 2.7.18。核心依赖包括Spring Web、MyBatis-Plus、MySQL驱动、Redis、Sa-Token、Lombok、Hutool工具包还有用于文件上传的commons-io。MyBatis-Plus是我特意选的它让我不用写大量重复的单表CRUD代码生成器可以直接生成实体、Mapper、Service。对于OA系统这种大部分操作都是单表管理的场景效率非常高。dependency groupIdcn.dev33/groupId artifactIdsa-token-spring-boot-starter/artifactId version1.37.0/version /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.5/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency工程内部按模块分包controller、service、mapper、entity、common、config、security。如果想做成前后端完全分离的微服务其实可以拆成认证服务、流程服务、消息服务几个独立工程但学院OA的并发和业务量完全不需要引入微服务拆了反而增加部署复杂度。单体应用在这个场景下是最务实的。3.2 JWT登录认证与拦截器实现登录接口做的事情不复杂接收用户名、密码、验证码先校验验证码再校验用户状态然后查数据库比对密码。密码用BCrypt加密登录成功后生成一个tokenSa-Token官网支持JWT模式可以直接集成。PostMapping(/login) public Result login(RequestBody LoginRequest req) { // 校验验证码Redis中保存的是图片验证码结果 String code redisUtil.get(captcha: req.getUuid()); if (code null || !code.equals(req.getCaptcha())) { return Result.error(验证码错误或已过期); } SysUser user userService.getUserByUsername(req.getUsername()); if (user null || !BCrypt.checkpw(req.getPassword(), user.getPassword())) { return Result.error(用户名或密码错误); } if (user.getStatus() 0) { return Result.error(账号已被禁用); } // Sa-Token签发token这里启用了jwt模式 StpUtil.login(user.getId()); String token StpUtil.getTokenValue(); return Result.success(Collections.singletonMap(token, token)); }权限控制我没有在每个接口上加SaCheckPermission注解而是在需要权限的接口上加一个自定义注解RequirePermission(oa:approval:submit)然后用拦截器统一切面校验。这样代码侵入性更小也不会漏掉控制。还有一个重要的安全逻辑不允许同一账号在多个浏览器同时登录。学院里经常会有人把账号借给同事用如果不做控制后面的操作会把前面的人踢下线反而不利于审计。我最终配置的是“同账号最多同时在线1个会话”如果有人重复登录旧token立即失效。这个策略在实际使用中评价很两极有人觉得方便有人觉得麻烦但站在信息安全和操作审计角度我觉得限制在线数量更稳妥。3.3 请假审批流程的完整实现我拿“教师请假审批”当核心例子讲。前端有一个请假申请表单包含请假类型、开始时间、结束时间、请假事由等字段。提交时后端会调用统一流程引擎接口传入processCode和表单数据引擎根据流程定义自动创建流程实例和第一个任务。流程提交的核心方法如下我做了简化但保留了主干逻辑Transactional public ProcessInstance startProcess(String processCode, MapString, Object formData) { ProcessDefinition def getByCode(processCode); ListMapString,Object nodes def.getNodeConfig(); if (CollUtil.isEmpty(nodes)) { throw new ServiceException(流程未配置审批节点); } ProcessInstance instance new ProcessInstance(); instance.setProcessCode(processCode); instance.setApplicantId(StpUtil.getLoginIdAsLong()); instance.setApplicantName(userService.getById(instance.getApplicantId()).getRealName()); instance.setCurrentNode(0); instance.setStatus(PROCESSING); instance.setFormData(formData); save(instance); // 创建第一个审批任务 createTask(instance.getId(), nodes.get(0), 0); return instance; } private void createTask(Long instanceId, MapString, Object node, int nodeIndex) { OaTaskInstance task new OaTaskInstance(); task.setInstanceId(instanceId); task.setNodeIndex(nodeIndex); task.setNodeName((String) node.get(nodeName)); // 根据assigneeType解析出实际审批人 Long assigneeId resolveAssignee(node); task.setAssigneeId(assigneeId); task.setAssigneeName(userService.getById(assigneeId).getRealName()); task.setStatus(PENDING); taskService.save(task); // 生成待办消息并推送WebSocket messageService.sendTodoMessage(task); }审批动作通过approve方法实现。审批人点“同意”时先写审批记录再把当前任务置为FINISHED然后判断还有没有下一个节点。如果有创建下一个任务如果没有流程实例状态改为APPROVED并调用回调通知申请人工单已通过。点“驳回”时流程实例状态改为REJECTED当前所有未完成任务都标记为CANCELED通知申请人修改后重新提交。这个流程设计里最需要小心的是并发问题。两个人同时审批同一个任务理论上只有一个人能成功。我在任务表加了version乐观锁字段更新任务状态时SQL条件是“status PENDING AND version 当前版本”更新成功才说明当前用户抢到了这个任务的审批权。实际测试中发现如果不做这个控制双击同意按钮会重复创建下一个节点流程就乱了。这是我踩过的一个挺真实的坑。3.4 前端Vue3页面设计思路与后端联调前端我按“后台管理框架”的经典布局来搭左侧菜单、顶栏信息区、主体内容区。菜单不是写死在路由里的而是用户登录后从后端获取。这样权限变了前端菜单也会跟着变。Axios请求封装是联调的关键。我统一设置了baseURL、请求头token注入、响应拦截器里的错误码处理。服务端返回401时自动跳转登录页业务错误码弹出Message提示。有一个细节文件下载请求不能走统一的JSON响应拦截因为返回的是二进制流如果拦截器强行转成JSON下载就会变成一堆乱码。当时这个问题排查了半天最后发现是响应拦截器把所有内容都用response.data做了JSON解析下载接口单独走了rawResponse才解决。前端表单设计我尽量用动态渲染。审批申请页是根据后端返回的formSchema生成的这样新增一种流程类型时不需要重启开发环境重新发版。比如新增一个“科研项目外出申报”管理员只要在后台配置好表单字段和流程节点系统就能自动生成可用的申请页面。这个能力在演示的时候效果好实际使用中也确实省了不少开发量。4. 部署过程、性能优化与常见问题排查4.1 从开发环境到生产环境部署的完整过程开发环境一切正常不代表部署就能顺利。我踩的第一个坑是服务器环境变量问题。生产服务器上JDK版本是8但代码里用了Java 17的语法特性启动直接报UnsupportedClassVersionError。后来统一在服务器装了JDK 17问题解决。我建议这类项目在配置里直接固定Java版本文档里写清楚别指望运维同事帮你去猜。后端部署我用了两种方式都验证过一种是直接把Spring Boot打成jar包扔到服务器上用nohup跑还有一种是Docker容器化部署。学院服务器资源有限最终选了jar包 systemd服务开机自启、崩溃自动拉起。为什么不Docker主要是运维同事对Docker不太熟而且单机部署jar包足够稳定没必要为了“用Docker”而用Docker。前端部署则相对简单npm run build打包后生成dist目录Nginx里做静态文件映射和反向代理。前端接口请求通过Nginx转发到后端服务同时上传的文件统一映射到本地存储目录。Nginx配置我给出一个可用的参考server { listen 80; server_name oa.example.edu.cn; root /data/oa-web/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /file/ { alias /data/oa-file/; } }部署完成后还需要做健康检查。我写了一个简单的shell脚本每5分钟访问一次后端健康检查接口如果返回不是200就自动重启服务并把日志写入固定文件。这个脚本看着粗糙但在没有专业运维团队的环境下很实用学院OA跑了一年多稳定性主要靠它保证。4.2 高频问题排查速查表问题典型原因解决要点前端请求后端跨域报错没有配置CORS或Nginx代理路径不对开发环境统一用proxy代理生产环境走Nginx反代登录成功后刷新页面又回登录页token没有持久化或路由守卫判断异常确认token存到了本地存储并在Axios拦截器注入上传附件超过Nginx限制client_max_body_size默认1m在Nginx配置中加大client_max_body_size待办列表查询特别慢没有建组合索引给assignee_id status建索引审批通过后流程状态不变事务没提交或乐观锁更新失败检查事务注解和version乐观锁逻辑服务器时间显示异常时区设置不对MySQL连接串加serverTimezoneAsia/Shanghai中文乱码字符集不一致数据库、连接串、项目文件全部统一UTF-8内存溢出默认堆内存太小启动命令加-Xms512m -Xmx1024m这里最值得展开讲的是Nginx上传限制。最开始我没注意到Nginx的client_max_body_size默认只有1MB附件稍微大一点就会收到413错误。这个错误跟后端完全无关问题在Nginx层。我在location块里加上client_max_body_size 50m后附件上传恢复正常。排查这种问题需要有思路先看Nginx日志再判断请求到底有没有到达后端一步步缩小范围。4.3 基于实际业务量的性能优化建议科技学院的OA用户规模大概是几百到一千人这类业务体量下不需要动不动就上MQ、分库分表、微服务。真正要关注的性能点其实很具体列表页查询不要拖慢待办数量刷新不要有压力文件上传下载不能卡。第一数据库索引要覆盖高频查询特别是流程实例表、任务表、审批记录表。第二流程表单的数据量不大但审批记录是线性增长的要对instance_id建索引并用分页查询。第三字典数据比如请假类型、会议室名称用Redis缓存起来返回前端时直接读缓存不查数据库。第四文件存储按月份分目录每个附件生成唯一的文件名避免单个目录下文件过多导致访问变慢。我做过一轮压测用JMeter模拟50个并发用户同时提交审批、查询待办数据库CPU占用在20%左右接口平均响应时间在150ms以内。这个数据对于学院OA来说已经足够有余量了。如果以后用户量涨到几千最应该升级的是给Mysql配置一主一从读操作走从库把查询压力分摊掉。还有一个容易被忽略的点日志优化。Spring Boot默认的日志体系在长时间运行后会产生大文件磁盘满了系统就卡死。我把日志按天滚动保留30天超过30天自动删除。这个操作虽然不起眼但在实际运行中救了无数次场。5. 系统测试、上线维护和个人实战经验5.1 功能测试和关键路径用例设计测试阶段不能只测“正常流程”还要把异常路径都覆盖到。我当时设计了这样几类用例未登录访问受保护接口、权限不足用户访问管理页面、同一账号重复登录、流程驳回后重新提交、附件上传超过大小限制、重复提交审批任务。这些用例在功能上看起来不多但每一条都对应一个真实可能发生的操作场景。有一个测试结果让我印象很深未登录用户访问接口时系统返回的是401状态码和JSON提示但在某些低版本浏览器上前端拿到401后没有正确处理跳转到了空白页。原因是路由守卫只处理了业务码为401的情况没处理HTTP状态码层面的401。后来我在Axios响应拦截器里增加了一行判断HTTP状态码为401时强制清空token并跳转登录页这个空白页问题才彻底解决。5.2 上线后持续迭代的几个经验第一上线不等于结束必须做用户培训和文档沉淀。我写了三份文档系统操作手册、管理员维护手册、开发者二次开发文档。学院里的行政老师需要的是“点哪里、点什么、会出现什么”这种保姆级图文说明而不是概念性解释。第二需求会持续变化流程配置能力就是核心竞争力。比如学校开学时突然要求加一个“教师返校健康报备”流程我当时只需要在后端配置一个流程定义和表单Schema前端页面自动生成。这让我意识到OA系统的长期生命力在于流程可配置而不是写死代码。第三备份不能偷懒。数据库每天凌晨自动备份文件目录每周全量备份到移动硬盘。有一次我误操作删了一张流程定义表靠前一天晚上的备份恢复到了几分钟前的状态数据只丢了一条测试记录。从那次之后备份脚本的重要性在我心里的优先级直接排到了第一位。第四安全问题要提前想。OA系统里有教职工手机号、身份证号、工资信息等敏感数据接口不能裸奔。我用Sa-Token做了登录认证和权限校验敏感接口全部加了鉴权注解文件下载也做了权限校验。系统上线后我还安排了每季度一次的安全自查重点看有没有越权访问漏洞。5.3 回头再看这个项目的几点真实感受现在这个OA系统已经稳定运行了快一年流程模板从最开始的6个增加到了15个用户覆盖全院教职工。回过头来看最初选择“不引入重型工作流引擎、自研轻量流程引擎”的决定是对的它让系统在需求和流程频繁变化的院校环境里保持了极高的调整效率。但我也要客观地说自研OA并非适合所有单位。如果是一个几千人的大型企业流程复杂、分支多、权限粒度细商业OA的稳定性和功能丰富度确实更强。科技学院OA能成功核心在于业务场景相对集中、流程结构足够清晰、技术团队能快速响应变化。如果你的单位也具备这几个条件自研就是一条值得走的路。最后再分享一个小技巧设计所有列表页时都要预留“导出Excel”功能。行政办公场景里老师几乎每隔几天就要导出一份审批台账或统计报表这个看起来不显眼的功能反而成了用户满意度最高的功能之一。功能优先级不需要追新求全能用、好用的功能一定是在真实需求里长出来的。